The U.S NSA and CISA have shared tips to secure the software supply chain. But is this actually a step in the right direction?
After the snowball effect of supply-chain attacks like the SolarWinds hack that compromised multiple U.S govt agencies (which brought about President Biden’s Executive Order on cybersecurity measures), it’s not surprising that we’re now seeing guidance on how to plug vulnerabilities in the software supply chain that nation-state-backed threat groups can easily exploit.
Developers play a key role in securing the software they create for their employers, but when that software is used as part of a software supply chain those responsibilities are even greater. Unfortunately, like much associated with the concept of “shifting left”, an expectation is placed on development teams that they are experts in risk assessment and can identify and protect against threats to how they develop software. What the Enduring Security Framework (ESF) recommended practices for developers guidance does is bring an impartial risk based perspective to how software can be developed in a more secure manner. While many teams might gravitate towards the checklist in Appendix D, the real value in the ESF guidance are each identified threat and the recommended mitigations. For some teams, those mitigations might already exist, but for others the risk-based model outlined can help justify why existing processes should change and what the outcome of such changes would be.
The best practices shared by the NSA and CISA lay comprehensive groundwork for organisations across the software supply chain to achieve the requirements established by President Biden’s 2021 Executive Order on cybersecurity. They represent a meaningful step in the right direction, even if they are arguably very high level.
The clear through-line in this guidance is that tooling and automation are critical for securing the software supply chain. If it hasn’t been hammered home enough, organisations must develop programs around secure supply chains, as well as software bill of materials (SBOMs) and software composition analysis (SCA). That’s not to say the guidance is perfect, because there are still holes to fill, such as advocating for a secure repository over SCA through a continuous testing model.
Overall, the recommendations offer comprehensive guidance to developers on software supply chain security. Clearly, there is a great deal of momentum behind software supply chain security at the moment, and a lot of best practice has been shared by government bodies and industry alike. Now, it is up to organisations and the wider developer community to put best practice into practice.