As software becomes more critical to organizations of all sizes and in all industries, and as the threat of cybercrime escalates, so does the need to protect the software supply chain. In the current situation, it is no longer a question of whether companies want to secure their software supply chain or not, but whether they implement this successfully.
By “software supply chain” I understand all the components of software and the process chain that is run through to create and introduce new software in the company. It encompasses all components used in an application, including code specifically created for it, open-source software, proprietary applications and third-party tools, binaries, builds, packaging scripts, and any dependencies required for the software to run. This includes the underlying infrastructure and even the automated build pipeline itself. All of these components and processes are potential vulnerabilities in the software supply chain that can compromise the overall security of software – and this is what poses a risk to a company and its customers represent.
A secure software supply chain depends in particular on three components:
- Development of clean code
Only clean code is secure code. In addition, clean code is the backbone of overall application security, development efficiency, and rapid release. If the code isn’t clean, it can cause a lot of downstream problems, especially if they are only identified after the code is already in production. In this case, it can be much more difficult to find and fix the cause.
During development, the cleanliness of the code must be ensured right from the start. This includes identifying and fixing errors by checking dependencies, analyzing code, signing binaries, etc. This incorporates software security measures early in the development process. It’s important for developers to understand and practice preventative security measures while creating code. However, if software security is viewed only from the perspective of software development, the importance of security in the deployment and productive processes is neglected. It is therefore important that the responsibility for security does not lie solely with the developers.
In particular, the following three tips apply:
- Know the provenance of all prepackaged artifacts you use to ensure they are validated, verified, and secure.
- Use a controller: The tool helps to proactively monitor the environment and spot problems so they can be fixed as quickly as possible.
- Automate your software delivery ecosystem as much as possible. This avoids human errors and oversights that later lead to problems and security vulnerabilities.
- Mean time to damage control metric
Often, once code is deployed, it seems to be “out of sight, out of mind.” But that shouldn’t be the case. Especially with frequent and fast releases, the team cannot sit back and relax after the deployment. Instead, it’s important to keep an eye on the code after an application goes into production and ensure that you’re able to respond quickly should a software security issue arise.
The troubleshooting process consists of two basic elements, identifying security issues and actually fixing the problem. A special metric has been established in the industry for each element:
- Mean time to detect (MTTD): This is the time it takes to discover a problem after the software is released.
- Mean time to repair (MTTR): This is the time it takes to fix the detected problem.
Of course, there is always a certain amount of time between the discovery of a security problem and its resolution. When faced with a serious security vulnerability, what is actually done in that time—between detection and remediation—is incredibly important. This is where new techniques like feature flagging and automatic rollbacks can help. In fact, these new techniques have led to a new metric gaining traction in the industry: Mean time to Mitigate (MTTM).
Damage control isn’t about fixing a problem. It’s about closing a vulnerability as soon as it’s discovered to limit the potential damage while the team works to develop a final fix. This could include shutting down a website or turning off an application or feature. When a vulnerability or vulnerability is mitigated, malicious actors are immediately prevented from causing further damage. It is now safe to proceed with fixing the underlying vulnerability.
- secure deployment
The third essential component of a software supply chain is to ensure security in the delivery of the software and the greatest possible integrity of the process. At its core, secure deployment is about monitoring all the things that can go wrong in the deployment process outside of the code itself. The important thing to remember is that without a secure pipeline, even if the code is beyond reproach, there is still a risk that malicious actors or human error could introduce problems.
To avoid this, you should follow three tips:
- Automate as much as possible. Automation eliminates human error and missed steps that can cause security issues later.
- Create access and permissions controls for the code and the pipeline yourself. To ensure security, you need to ensure that the right people have access to all relevant aspects.
- Build and continuously update a catalog of immutable objects. Immutable objects prevent people from modifying the code after it’s deployed. While this may not matter as much in a test environment, in production it can mean the difference between a successful software product and a failed one.
The responsibility of avoiding vulnerabilities and minimizing risk can become a real burden. Knowing where to start and ensuring that the right controls are applied to all components of software delivery can lighten the burden of that responsibility. Developing clean code, mitigating security issues, and making the software delivery process as secure as possible are steps that can help fight off malicious actors and security breaches.