Empowering developers through security

The historical issue

The Linux ecosystem has always strived for a high degree of quality. Historically, it was the sole responsibility of the community to package software, gating each application update through a careful review process to ensure it worked as advertised, and on each Linux distribution. This proved difficult for everyone involved.

User support requests and bugs were channelled through the Linux distributions, where there was such a volume of reporting that it became difficult to feed information back to the appropriate software authors.

As the number of applications and Linux distributions grew, it became increasingly clear that this model could not support itself. As a result, software authors took matters into their own hands, often picking a single Linux distribution to support and skipping an application store entirely. They lost app discoverability and gained the complexity of running duplicative infrastructure.

Waking up to the threats

The past year has demonstrated for many that, while software updates have not become substantially easier for end users to manage, the frequency and impact of security vulnerabilities make the process unavoidably necessary. It is no longer acceptable to consider any connected software a finished product. Software maintenance must stretch to cover the entire lifetime of the product, especially in today’s connected world.

This realisation was made even more prominent by the likes of Spectre and Meltdown – a huge wake-up call for every industry. It did not matter what space you worked in, it very likely affected normal business. Add to this the rise of robotics and edge computing, which bring more devices online, and the threat becomes even more widespread.

Canonical carried out research with IoT professionals, and found that over two thirds of respondents felt that a lack of an agreed industry security standard worried them when it came to IoT. To further compound the issue, nearly a third of respondents claim they are struggling to hire the right talent when it comes to IoT security. So the problem does exist, and there is widespread awareness, but without the right skills, businesses are relying on their developers to ensure that their software is robust.

Increasing pressure on the developer

This has placed increased responsibility on developers at a time when the expectations of their role are already expanding. They are no longer just the makers behind the scenes; they now bear the risk of a breaking robot arm with their code, for example, or bringing down MRI machines with a patch. As an industry, we acknowledge this problem without acting on it. You can have a bad update because software is not an exact science - but we then ask these developers to roll the dice and compromise on security for the sake of innovation.

On the other hand, developers can trade the evolution and growth of their software for a sense of safety, by treating their code as immutable. A device can ship and it will never be updated. Developers are being driven to this approach taken by those device makers who view clogged support lines as being much more inconvenient than facing down a security breach. The industry continues creating ever more software components to plug together and layer solutions on top of. Not only does the developer face the update question for their own code, they must trust all developers facing that same decision in all the code beneath their own.

How then can developers under these pressures deliver on the promises of their software with predictable costs? The challenge does not have a silver bullet, but a solution may just lie in snaps.

Extending the arsenal

Snapcraft is a platform for publishing applications to an audience of millions of Linux users. It enables authors to push software updates that install automatically and roll back in the event of failure. The likelihood of an errant update bricking a device or degrading the end user experience is, therefore, greatly reduced. If a security vulnerability is discovered in the libraries used by an application, the app publisher is notified so the app can be rebuilt quickly with the supplied fix and pushed out.

Because snaps bundle their runtime dependencies, they work without modification on all major Linux distributions. They are tamper-proof and confined. A snap cannot modify or be modified by any other app and any access to the system beyond its confinement must be explicitly granted. This precision definition brings simpler documentation for installing and managing applications. Taken with automatic updates eliminating the long tail of releases, more predictable and lower support costs are typical. There is minimal variance between what the QA department tests and how the application behaves on the end user system configurations.

Snapcraft also provides powerful tools to organise releases into different release versions (channels). One set of tools can be used to push app updates from automatic CI builds, to QA, beta testers, and finally all users. It visualises updates as they flow through these channels and helps you track user base growth and retention.

Empowering developers with the confidence to build

The difference between a real threat and a hypothetical one is not that different. You essentially have to ‘build for failure’; assuming that something ‘cannot go wrong’ will cost you the most when it does because you don’t have a plan.

This is the approach taken by snaps. Instead of treating software updates as a risky operation and only employing them in the rarest circumstances, snaps acknowledge that updates will fail. When they do, the snap rolls back to the last working version, all without the end user experience being compromised. The developer can then investigate without time pressure.

But because software-first companies are created all the time it places untold pressure onto these teams. There needs to be a compromise and it shouldn’t be in security. We’ve seen in the past year the kind of damage that cyber-attacks can cause. The stakes are too high to ignore the capabilities that the likes of snaps can offer.  

Developers are the lifeblood of so much of what is being built, and are ever more vital to operations across the entire business. So why wouldn't we empower them? Whether you’re building for a desktop, cloud, or IoT solution, embracing open source and snaps will keep users up to date and make system configuration issues less likely, freeing developers to code more and debug less. By following this lead, developers will have the time, but crucially the confidence, to continue building great things.