To varying degrees, most techies are aware of the security vulnerabilities identified in the OWASP Top 10 (SQL Injection, trying to homebrew Identity management etc), although I still sometimes have conversations where I feel the need to get the yellow or red card out. But the bottom line is that these risks are perhaps more appreciated because it is easier to understand external entities attacking seeking direct attacks to disrupt or access information. But there are often subtler and at least more costly to repair attacks such as internal attacks and indirect attacks such as compromising software deployment mechanisms.

This, later attack Is not a new risk, as you can see from the following links, been recognised by the security community for some time (you can find academic papers going back 10+ years looking at the security risks for Yum and RPM for example).

• Survivable Key Compromise in Software Update Systems
• Consequences of Insecure Software Updates
• Attacks on Package Manager
• The Problem of Package Manager Trust

But software is becoming ever more pervasive, we’re more aware than ever that maintaining software to the latest releases means that known vulnerabilities are closed. As a result, we have seen a proliferation in mechanisms to recognise the need to update and deploying updates. 10 years ago, updating frameworks where typically small in number and linked to vendors who could/had to invest in making the mechanisms as a secure as possible – think Microsoft, Red Hat. However we have seen this proliferate, any browser worthy of attention has automated updating let alone the wider software tools. As development has become more polyglot every language has its central repos of framework libraries (maven central, npm, chocolatey ….). Add to this the growth in multi-cloud and emphasis on micro deployments to support microservices and the deployment landscape gets larger and ever more complex and therefore vulnerable.

What to do?

Understanding the risks and recognising consequences of risks being exploited is the 1st step. As my lecturer said once, when explaining bystander theory to overcome an undesirable behaviour then it is necessary to make people of aware of the behaviour and how a change can be positively beneficial individually.

This means understanding that deployment mechanisms can be subverted if not properly secured. So, looking at the mechanism and the provider and asking how they secure it should be one factor. Taking the time to understand common attack vectors…

• Metadata Replay – hijacking an update’s metadata so that it results in the installation installing an older software version with a known vulnerability
• Mirror Control – replace a package in one of the official mirrors with poisoned content. That content, in turn, gets replicated as mirrors get cached more locally
• Endless Data Attack – send a large stream of data to repositories or update clients to overwhelm them
• Extraneous Dependencies – not every dependency used maybe secured, so poison a dependency that gets pulled in with an installation.
• Unsatisfied Dependencies – metadata or inherited dependency is vulnerable to having a dependency on non-existent packages

If you can’t get that assurance when examining a solution, then put mitigations in – for your desktop, control when the updates are applied, and run security tooling immediately afterwards. A lot of the sites that look at these problems to identify mitigation strategies. When developing solutions, if you’re proposing a distributed deployment framework then choose one that addresses the risks. This is where the CNCF has just graduated another project (see here). The Update Framework (TUF) has been designed and developed to directly address the known attack vectors of deployment processes.

TUF provides both a standard and a reference implementation. The reference implementation has been built using Python, so if this not of help then at least the standard can be used to either build your own implementation or look for one that is compliant.  I’d imagine that the bigger members of CNCF (such as Oracle, Microsoft, Pivotal, Google and others will adopt TUF and use the reference implementation and possibly provide alternate implementations – Afterall one good basic security step is to not add another dependency like Python if you don’t need it).

Additional sources of useful information in this area:

• NYU catalogue of projects in this space – https://ssl.engineering.nyu.edu/projects
• common attack vectors – https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation
• CERT Organisation at CMU – https://www.sei.cmu.edu/about/divisions/cert/index.cfm