When three U.S. government agencies get together to “strongly encourage” developers to adopt certain practices, you should pay attention. The CISA, NSA, and ODNI, in recognition of the threat of cyber-hackers and in the wake of the SolarWinds attack, announced that they will be jointly publishing a collection of recommendations for securing the software supply chain to prevent such vulnerabilities in the future. The announcement made it clear that the purpose of the document is to encourage developers to adopt best practices, stating that “These principles include security requirements planning, designing software architecture from a security perspective, adding security features, and maintaining the security of software and the underlying infrastructure.“
This guidance is organized as a three-part series and will be released coinciding with the software supply chain lifecycle. Part 1 of the series, which focuses on recommendations for software developers, has been released in August 2022. The remaining two parts will be released in the near future: part 2 will focus on the software suppliers and part 3 will focus on the customers receiving the software. The ultimate goal is that this series will help foster communication between these three key stakeholders and among cybersecurity professionals to facilitate increased resiliency and improve overall software supply chain security.
While it isn’t always clear whose responsibility it is to ensure software security, regardless of who may bear overall responsibility in your specific organization, this new guide makes it very clear that all developers should become familiar with these new best practices and that they all have a role in securing the software supply chain. Or, if I may be more blunt: Developers, you play a critical role in securing your organization’s software supply chain! And for that reason, we thought you might find it handy to read a (relatively) short summary of this first part of the guide, just for you. Here it comes.
The guide in a nutshell:
Among the extensive lists of potential threats referred to in this practical guide for developers, there are a few key vulnerabilities that have been identified and you should make sure to address and prepare for them:
- Features that have not been properly documented or that implement risky functionality
- Under-the-radar shifts in the core security assumptions between the time of the security assessment and code delivery
- Corporate changes to supply chain stakeholders
- Sub-standard coding or security practices
Management, finance, and program managers all have a responsibility to address the security of the software supply chain, but the integrity of software supply chain security often depends on the vigilance of software developers and awareness among all supply chain stakeholders. Part 1 of the guide focuses on the role of developers and the threats that are inherent to each stage of the development process, and offers recommendations for mitigation strategies that should become standard practices.
Stage # 1: Secure product criteria and management
Secure development starts with recognition of the importance of software supply chain security by all key stakeholders in the product and development teams. The threat scenarios are common and may be clear to everyone; the challenge is to get everyone on the same page with regard to the mitigation policies that have been decided upon. These policies must cover the entire process: the design and architecture, the threat modeling, the coding, the security test plans, the release criteria, and how to manage vulnerabilities in the future. Part of this also includes assessing the teams’ capabilities and ensuring they’ve been properly trained for their tasks and then defining documentation practices and periodic security reviews and threat assessments.
Stage #2: Secure code development
When it comes to code development, the correct practices for secure coding have already been laid out in the SSDF. This is the reason that, to the extent that the programming language has not been predetermined, security considerations should be part of that decision as well. The guide supplies useful guidance for developers, addressing a wide range of scenarios, such as the insertion of harmful source code by ‘insiders’ (e.g., developers), open-source software and the best practices for dealing with it. How to create a secure environment for coding (including secure build configurations and 3rd party software tools) and subsequently test the security of an integrated product. Since vulnerabilities are likely to crop up after delivery as well, there are also recommendations for dealing with reported vulnerabilities and ensuring that future external software extensions do not compromise the security integrity of the product.
Stage #3: Harden the build environment
Once the code has been developed securely, software supply chain security requires that the build environment be hardened to the same standards as the software itself. Compromising the build system is an attractive way to infiltrate the code, since it comes at a stage of the development process that is naturally less scrutinized by developers.
Stage # 4: Code delivery
The final weakness addressed by the guide covers the final stage of the software supply chain—code delivery. Even when the code has been properly secured all the way up to this point, there are still two key supply chain vulnerabilities that must be mitigated. The first is final package validation, which can be exploited, for example, by inadvertently exposing metadata, developer credentials, or the open-source inventory. The other step that is often probed for weaknesses is the distribution system, which could be compromised by a man-in-the-middle attack that can take over one or more stages in the delivery.
By applying these risk-mitigation practices at the software development level, software vendors can avoid weaknesses that can lead, for example, to the infiltration of updates, code signing manipulation and “surprises” hidden in open-source-code.
No such thing as a free lunch: The hidden cost of 3rd party software
A key contributor to developer velocity has become the ability to effectively incorporate 3rd party software. This has made it possible for developers to focus, for example, on innovation or function, while using ready-made components for scalability or interfaces. This increased use of 3rd party software has created a major challenge to software supply chain security. In addition to conducting an assessment of such code in accordance with the same standards used to assess your own, the guide suggests scanning the binaries for any vulnerabilities and evaluating the resulting risks. The results of this evaluation should factor into the decision to use or not use a specific software component. The selection of a software component must also take into account its source; incorporating 3rd party components into your source code is the start of a long relationship and you should strive to work with partners you can trust. Code ownership, coding practices and version management policies are just a few points to consider when selecting a trusted source. Just think of all the future updates, releases and maintenance work for each component as new threats are discovered. The challenge will be to monitor all the 3rd party changes, assess for vulnerabilities and respond accordingly, sometimes under severe time pressure.
Boost your software supply chain security with an SBOM
One key practice to ensure the long term integrity of your software supply chain is to maintain an updated Software Bill of Materials (SBOM). The SBOM is a detailed inventory of the software components that comprise a given solution.
This will save you time and effort, and most importantly will reduce your exposure to ongoing threats. Each software component that is incorporated into your product should come with its own SBOM, which must be validated and merged into a single ‘master’ SBOM for the product. If you intend to incorporate components that do not come with an SBOM, you will need to conduct your own analysis using software composition analysis (SCA) tools.
The more accurate and descriptive the SBOM, the easier it is to maintain and reference. Given the dizzying rate at which software components are updated, a well-structured SBOM will pay dividends when it’s time to track down and record every update, patch, or release. Even more importantly, once a security threat is discovered, every moment is critical. Remember: The security of your software supply chain will always be as strong as your weakest link. When there are dozens of software components at risk, you’ll be grateful for an SBOM that has all the answers.
For an efficient workflow, a useful SBOM should at least include these three components:
- Data fields – These are the descriptors for the components you have implemented. Being able to easily identify which components have been used, even long after the development has been completed, helps to effectively monitor them for vulnerabilities.
- Automation support – Automatic monitoring of the SBOM requires that they also be identified in one of the accepted machine-readable formats.
- Practices and promises – Managing an SBOM requires a common understanding of maintenance practices, such as frequency of versions, dependencies, known unknowns, distribution and delivery, access control, and how to accommodate mistakes.
Sharing the SBOM among the stakeholders of a specific product (the software developer, the software supplier, and the customer) helps promote transparency and alignment, increasing the ability of a software supply chain to defend the product against security threats. It must be noted that, given all of the moving parts in a software supply chain, consistently maintaining such an SBOM—one that can be easily referenced, monitored, and maintained—is a complex challenge.
Final words: How can you take your software supply chain security to the next level?
As software supply chain security becomes more and more crucial, organizations are being repeatedly challenged to build transparent trust in the software they deliver or use. Since the adoption of the SBOM as a best practice is expected to grow, having a tool that enables you to overcome this challenge is a key step toward establishing software supply chain security. This is why we have recently launched the first evidence-based security hub for software products, enabling its users to build trust in their software across teams and organizations. This user-friendly platform will help development teams mitigate software supply chain risks by making the SBOM accessible, easy to use, and most importantly—make software products’ security transparent to customers, buyers, and security teams.
If you, as a software developer, are concerned with the threats to your software supply chain security, we urge you to try out the platform; it is free to use, no strings attached. By implementing our workflow, you’ll be able to share your SBOMs across your supply chain.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
