Software Security Overview
In this new series we talk about the security aspects of the software development lifecycle, including some of the various threats, compliance requirements, and software distribution techniques. As part of this, we look at how to manage the components that go into a modern software application, how the infrastructure can impact this, and ways that developers and system owners can protect themselves.
The development landscape is complex and changes frequently, so it’s often good to revisit core security concepts and considerations to ensure that a developer or team is properly focused. Often people will follow the well laid tracks of the past, and developers are no exception. Revisiting assumptions made in the development, validation, and distribution of software products periodically is important to find opportunities to improve the security and maintainability of a system.
The start of this series is a review on the security aspects of the software supply chain, and to detail how this landscape can impact software applications.
What is the Software Supply Chain?
Put simply, the software supply chain is much like the physical goods supply chain that may be used for a factory to produce products. The inputs that go into a software application, ranging from development tools and hosting infrastructure on through artifacts and dependencies that are incorporated into an application are all part of this supply chain. Any component, system, or service that interacts with or is inserted into the application code should be considered part of the software supply chain.
Modern development tools create a very dynamic environment with external AI calls for augmentation, build and scan services to process source code, and the seamless import of artifacts and components, so tracing and defining the software supply chain can be complicated. A simple project in a modern IDE may have a range of dependencies, plugins, and other automations that have processed or interacted with application code with little accountability.
Recent events where NPM and PyPI packages have been tampered with to introduce malicious code or other back doors, or even simply broad software vulnerabilities like the Java log4j incident, highlight the risks to developers. Infrastructure incidents like Solar Winds or the Team City compromises further highlight the issues in maintaining security of a baseline, or recovering to a secure and verified state after an event has occurred.
Given the nature of dependency management, the external source code may not be immediately inspectable, is generally not part of a code scanning process, and yet these external components have full access to your application runtime. A software component to render an image may also be able to make network connections, read environment variables including API keys and access tokens, and perform a range of other unrelated activities. In some of the examples above, the previously valid libraries were compromised to steal keys, passwords, and other information.
Even beyond directly malicious code, critical system artifacts may be abandoned, unsupported, or otherwise a long-term support consideration. Many libraries and components in widespread use have not seen updates in years, leading to unfixed issues and vulnerabilities. Incorporating these in a software application may be functionally beneficial, but could have severe consequences.
Having a software application developed with best practices, careful development teams, and code scanning may not find these external risks to a system. This is the crux of software supply chain management.. the accountability of all components, not just application code, in the overall software solution.
Implicit Trust Relationships
As libraries and packages are incorporated into an application, and external services used to process application code, there is a trust model established with these sources. The simple act of importing a library into an application is a concrete statement by a developer stating “I trust this source.”. This is important and often glossed over, as a developer is simply looking for a function or capability for a system. Generally the developer is saying “I need a QR code Generator.” Or “I need a CSV rendering library.”, but the actual statement is “I need a defined function from this dependency, and I assume it does not do anything beyond that even though it’s executing in my application context without constraints and other validation.”. That statement is a bit more comprehensive, but not particularly appealing.
Even if a function or service is desirable, the effort must be made to determine if the component or service is trustable, supported, and deserving of the trust being placed in the component.
Accountability
Ultimately the management of your software supply chain is about actively managing the cost/benefit to artifacts and infrastructure used in the development and release of a software product. Rather than implicit relationships and untracked components introducing risk, there is a direct engagement to plan and mitigate any necessary risks, while avoiding unnecessary ones. Simple CVE counting is not effective at understanding the actual security posture of a system, and this in-depth holistic management is a much more effective process. The tracking of the software component provenance, trust, and composition will be detailed in this series.
Next Steps
With this starting baseline, the next post will proceed to talk about software packaging and distribution. Container-based software solutions have many options and many subtle threats and concerns. This domain includes managing the provenance of all parts of a software system, the tracking of Software Bill of Materials (SBOM) information, and how to have a proactive view of the overall security of a system. This will be explored from the security foundation of a base image up through installing your software into the system for use.