Rather than preparing for the worst, the race to grab market share in IoT has vastly increased pressure on developers to deliver without a thought for the consequences or potential risks. Software-first companies expect new innovations 24/7 but are not always enabling developers to make allowances for security – or worse, leaving it the hands of the end-user to constantly update their applications.
We’re reaching a tipping point and developers are right in the middle of this scale. To continue building, we must acknowledge the threats and embrace the tools to tackle them.
Hackers don’t discriminate
It is no longer acceptable to consider any connected software a finished product. Software maintenance must stretch to cover the lifetime of the product. In 2017, Canonical carried out research with IoT professionals, which showed that over two thirds felt a lack of an agreed industry security standard put the IoT at risk.
As a first step on the road to a more secure connected ecosystem, Canonical created snaps – to allow any developer to publish an application (snap) to an audience of millions of Linux systems and connected devices. In the simplest of terms, a snap is a containerized software package, meaning it cannot modify or be modified by another snapped application. Any access to the system beyond its confinement must also be explicitly granted by the owner to ensure its ongoing validity.
Containing the threat
The thinking behind this format was twofold: convenience for the developer; and security for the end user. The point of the snap package is that it uses the same underlying security mechanisms as containers: they’re confined from the OS but can still exchange content and functions with other apps according to policies controlled by the administrator, through the Snap Store. Snapped applications cannot peer into the storage of other snaps, nor by default see into the system storage.
It’s important for snaps to operate this way because it allows for more advanced features to be built into the format. Snapcraft, the tool to build snaps, enables authors to push software updates that install automatically and roll back in the event of failure. The likelihood of a renegade update compromising the snap is, therefore, greatly reduced. If a security vulnerability is discovered in the libraries used by an application, the app publisher is simply notified so that the snap can be rebuilt quickly with the supplied fix.
We feel that others should follow this lead because it not only streamlines the process for developers, allowing them to spend time on what really matters, but also helps guarantee IoT security. In bundling their runtime dependencies, snaps are more easily managed and distributed – a single build artefact can target multiple Linux distributions. And as they’re both confined and tamper-proof, snaps remove many of the pitfalls developers face when rushing solutions to market.
The vital developer role
Before Snapcraft and snaps, many developers traded the evolution and growth of their software for a sense of safety, treating their code as immutable. It would ship and never be updated. That’s because many device makers often view a clogged support line as more convenient than a security breach. However, with snaps, developers can reclaim the role of chief innovator through a new-found sense of confidence. Confidence in their own software but also in the layers beneath them from other developers.
The surface area of software is expanding. Snaps support the developer, who has found his role to be all-encompassing, with all the expectations that come with it. Snaps were created to arm them with the tools to match this new job description. The added layers of security will help developers create in confidence, leading to the next generation of applications. Security should act in the background as the enabler, not the primary focus of developers, whose time is already stretched to breaking point. Snaps can be the solution.
No comments:
Post a Comment