ShiftLeft Academy

DevSecOps and the Software Supply Chain

Posted on

by

Steve Lipner is executive director of SAFECode, a global nonprofit organization formed in 2007 to identify and promote best practices for developing and delivering more secure and reliable software, hardware and services. Prior to that, Mr. Lipner was behind Microsoft’s drive for the Security Development Lifecycle (SDL) and Trustworthy Computing initiatives.

shiftleft-1

The recent and highly-sophisticated SolarWinds attack renewed attention to the growing risks in the software supply chain. These types of attacks are usually state-sponsored and they usually succeed because they abuse the trust between software vendors and their customers along the supply chain. In this case (as in 27% of cases according to a SecurityBouleveard survey), the attackers inserted malicious code into the update builds of the trusted vendor.

This supply chain attack invalidated the trusted code-signing certificates that attest to the integrity of the code being pushed out to the supply chain. Supply chain attacks can also exploit code-level errors such as overflows or poison open-source components used to build the application. Even developer tools are under attack, according to the SecurityBoulevard survey.

In this interview, we ask SAFECode executive director and Microsoft veteran Steve Lipner about the role developers play in protecting the supply chain and how they can protect their products from being subject to these types of attacks.

What is a Supply Chain?

In his article, “Untangling Supply Chain Security,” Lipner defines the computing supply chain as all of the organizations (software and hardware) that contribute to a computing product. He writes, “The supply chain includes the manufacturer of the computer that’s delivered to the loading dock as well as the organizations that create the software that comes pre-loaded on the computer, and the suppliers of parts and subsystems that the manufacturer builds into the finished computer system.”

Who’s Responsible?

The first thing, he says, is that security of the supply chain itself is not solely the developer’s problem to solve. The developer’s role is to develop code free from bugs and design issues that can be exploited to undermine the trust of their applications and updates. Securing the computing environment where builds, programs and updates are under development rests with the enterprise IT security and operations departments who must collaborate with the development team to prevent unauthorized access to those systems.

What’s Your Advice to Developers?

“On a high level, developers need to follow a secure design approach, understand what the threats are, and have plans for mitigating them. If you are not already following these practices, clean up your own house and team,” he advises. “Fundamentally, development teams need to be onboard, trained, equipped and motivated to do secure development (sometimes referred to as DevSecOps). The design approach should include basic coding standards that help developers avoid building apps with exploitable bugs and operational vulnerabilities.”

Pro Tip: Sourcecode analysis and workflow management can be automated through source code analysis tools, including static and binary analysis tools that are developer-focused.

More difficult is inspecting third party components, including open source, for bugs that can be exploited by supply chain attackers.

Pro Tip: Check out Google’s new Open Source Vulnerability (OSV) website to find, classify and repair bugs faster.

“You have to also affirm trust with the external organizations and individuals that you’re relying on to build and maintain their parts in the supply chain. You need confidence that the external developer exercises control over its code repositories and build environment and confirmation that you are receiving what the supplier intended, usually through code signatures,” he continues. “Map code dependencies and assess risk of those components, including updates and changes.”

Pro Tips: Read SAFECode’s paper on how to identify, assess and manage the security risks associated with third-party components. Also check out GrammaTech’s Automated Software Engineering Library to enhance development with secure, tested components.

“Developing in safe languages and with trusted frameworks are also important. For example, take special care when developing software in C and C++, which are almost optimized to create buffer overrun vulnerabilities and other errors that result in exploitable risks,” he adds.

Pro Tip: If you must use C languages, here are some best practices from GrammaTech.

How Do You Ensure Product Integrity?

“The rules about secure development and protecting the integrity of your product and the way it’s delivered apply to everybody in the supply chain. That means assuring the software that you’re building through secure development. It also means protecting your libraries, source code, repositories, and build systems from external attacks, such as malicious tampering (making it do things you didn’t want it to) or counterfeiting (replacing components with malicious ones).”

In an ideal world, development and IT security would work together to achieve both objectives.

Related Posts

Check out all of GrammaTech’s resources and stay informed.

view all posts

Contact Us

Get a personally guided tour of our solution offerings. 

Contact US