Software Supply Chain Security
Today, open-source software is everywhere. In modern software development, it is so common to integrate external dependencies into your software to avoid reinventing different tools. Using off-the-shelf solutions and integrating the dependencies to your software can make your team more productive and focus on your core business. With this software development approach, the team can focus on the actual business needs instead of a lot of technological inventions and it can increase the development velocity.
By integrating external dependencies, your software will form a software supply chain at the end. For example:
From the dependency graph above, we can know there are different software suppliers at different supply chain stages. These software suppliers provide different functionality to your software like web client, database operations, data serialization, etc., with these suppliers, we don’t need to spend a lot of effort to reinvent these kinds of tools and the development team can focus on what they really need in the company.
Although this development strategy provides some benefits to us, it still has some problems that we need to care about like vulnerability and license. During software development, we should notice what dependencies are integrated into the software supply chain. If you are not aware of how many dependencies are integrated into the software supply chain and what are those integrated dependencies in the software supply chain, it may cause different security vulnerabilities in your own software depending on the upstream vulnerabilities.
A famous logging framework called Log4j had a critical zero-day vulnerability in 2021 (Read more: Log4Shell) and it affected a lot of software in the world because these software integrated this logging framework into their software supply chain. Since Log4j was the upstream supplier of a lot of software, so it affected a lot of downstream consumers back then. Imagine if you are not aware of the vulnerability, you are putting your software at security risk and giving opportunities to attackers. It is so common that the vulnerability is not from your software but from your upstream suppliers. So be aware of the vulnerability of your upstream suppliers.
The software supply chain security is not limited to code dependencies but also the whole CI/CD process including the run-time environment, developer practices, and everything before production.
To reduce security risk in your software supply chain from a software engineer's perspective, few things that we can do before deploying to production:
Secure coding guideline
We should form a secure coding guideline to enforce the team to follow good security practices during coding and educate the software engineers about secure coding.
Monitor software dependencies and send vulnerability alert
We can use the existing scanning tools to monitor the software dependencies, for example, Trivy, Snyk, etc., these tools can help us be aware of the vulnerabilities in the software supply chain and we can assign engineers to fix the found vulnerabilities to prevent security issues.
Static code analysis
Static code analysis tools like SonarQube and FindBugs can be used to improve the code quality and security in the codebase and enforce software engineers to follow good practices and reduce potential risks before deploying to production.
Code review
Review your peer’s code and reduce potential security risks before deploying the code to production. It is good to have peer code review during development time because good teammates can complement each other and make the code better.
In conclusion, the software supply chain is not only at the coding level but the whole CI/CD process. The team should follow good security practices to avoid potential security risks including secure coding, dependency vulnerability monitoring, static code analysis, code review, etc., we should create a good security culture in the team to against security risks.