By now most information technology managers are painfully aware of the consequences of software supply chain attacks. Thanks to exploits affecting the supply chains of SolarWinds,  Log4Shell and 3CX, the power and widespread damage inflicted by these attacks on thousands of businesses are certainly well-known.

To try to remedy things, a raft of new supply chain security providers has launched this summer. They include Ox Appsec Security Ltd., which integrates ChatGPT for better protection, as well as Stacklock, which provides better cryptographic code signing, and Sonatype Inc., which creates open-source software bills of materials, just to name a few. These complement many of the longtime software security providers such as Palo Alto Networks Inc.’s Prisma Cloud and Veracode Inc., which have been offering general app security for years.

The trouble with these supply chain exploits is that they have multiple causes. First off, there is no unified governance model that includes all stakeholders: developers, end users, customers and corporate managers. Often these various groups have conflicting purposes and goals, or don’t know how to evaluate the security of their software components, or even know what components they are using.

Many developers rely on dozens if not hundreds of open-source projects, any one of which could be compromised and become tomorrow’s headline exploit. On top of these issues, the development pipelines can’t easily integrate with existing security software, compounding the risks involved.

No matter what caused a supply chain disruption, the important matter is how IT can learn from these bad practices and build better cloud apps. That’s where the National Institute of Standards and Technologies comes in. It has a new collection in the draft document entitled, “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines,” which was published late last month. The goal is to help hasten the integration of various software supply chain security measures into these development pipelines and frameworks.

The strategies are part of a larger NIST series on best practices in DevSecOps and secure software development frameworks, along with other government-backed efforts. That’s on top of a joint set of recommendations from the National Security Agency and the Cybersecurity and Infrastructure Security Agency that was issued over the summer aimed at improving development pipeline security. Both agencies also released a set of developer best practice guidelines in September 2022.

The NIST draft tries to draw a distinction between finding a software bug that is an unintentional defect and one that is exploited by an attacker for malicious purposes. The exploit could be mounted by a hacking group that is specifically targeting particular end user businesses, or it could be the result of a disgruntled employee seeking revenge.

It could also run the gamut of injections into the source code of a particular project or testing environment, or it could include stolen account credentials from a social engineering ploy. Each of these scenarios is spelled out in terms of the potential security consequences, and what steps are needed to prevent them from happening.

Those IT managers familiar with the software development lifecycle will probably find the draft elementary, but for those who aren’t involved in the field, it provides a common knowledge base to help move discussions about software supply chain security forward.

The draft goes into detail about how to take specific steps, such as to “identify the granular authorizations to perform various tasks, such as generating and committing code, generating builds and packages, and checking various builds and packages into and out of the code repositories.” Each of these is described further in terms of the security steps needed.

Comments on the NIST draft are welcome and are due before Oct. 13. They can be submitted via email to this address.

Image: Google