Post Credit: Austin Miller
Agile software development companies are everywhere now, and the speed of the software supply chain is only getting faster. But the real-world knock-on effect of that is twofold:
- DevOps teams and security teams (or a combined DevSecOps team) have less time to check the quality of new code and identify cryptographic failures, vulnerable and outdated components, or identification and authentication failures built into the software.
- The quick turnaround time requires developers to turn to potentially untrusted sources or outright malicious code that the adversary will easily exploit.
While security professionals always shout “shift left!”, it’s apparent that there are development teams out there that do not have sufficient integrity verification processes that allow them to analyze their work and protect their users against malicious code.
For that reason, it’s important to example number 8 in the OWASP Top 10 list – A08: Software and Data Integrity Failures.
What happens when there are poor integrity checks?
The most famous example of a failure in software and data integrity checks is the SolarWinds Orion attack, with the now infamous attack centering around compromised update mechanisms.
After hacking into the SolarWinds backend through password spraying or some other form of brute force attack – with the concerningly weak solarwinds123 being the way in for the attackers – the suspected nation-state attackers inserted malicious code into the SolarWinds CI/CD pipeline.
The SolarWinds.Orion.Core.BusinessLayer.dll component was introduced into the SolarWinds update pipeline and signed off as a SolarWinds approved software update with legitimate digital signatures. This compromise in the software supply chain meant that the update was legitimate as far as SolarWinds and its customers were concerned.
Of course, this is only one example of monitoring failures that have led to system compromise and critical data being exposed to the internet. But if SolarWinds had better processes for monitoring its own updates, this would not have happened.
Want to find out more? Check out this SolarWinds report by TechTarget.
What do software and data integrity failures look like?
The fast-paced world of development means that software and data integrity failures often because an application relies on unverified components. These components are pulled from the web and the developer does not have the time to verify them, which in turn leads to known vulnerabilities in the software making their way into the release product.
To check for software and data integrity failures in your applications, look out for these signs:
- Developers do not build code and application infrastructure with an integrity check in mind – security checks are performed at the end of the CI/CD pipeline, meaning that vulnerabilities are more difficult or impossible to address without impacting deployment.
- An insecure CI/CD pipeline generally underpins most software and data integrity failures. Without secure processes (including shifting security left in the pipeline), there is no way to know if known vulnerabilities have made their way into the code. Without basic procedures such as pentesting, security logging, vulnerability scanning, and static code analysis, a development team is only making assumptions related to the application’s security.
- Many applications rely on plugins, libraries, and modules from untrusted sources, repositories, or CDNs, but there is a chance that even the most trusted repositories could become compromised. All known sources must be thoroughly and regularly checked to avoid critical problems like Log4Shell appearing again.
- Auto-update functionality should not be implemented without a sufficient integrity check for all updated components. Similar mechanisms could have stopped the SolarWinds compromise.
How can I improve my approach to software and data integrity?
Although maturing to a DevSecOps culture is the best-case scenario for large organizations, better security practices throughout the development pipeline can be easily implemented to bolster an organization’s security posture.
- Implementing basic tools such as Static Analysis Security Testing tools (SAST), Dynamic Analysis Security tools (DAST), and Vulnerability Scanners can identify problem areas in the code which need urgent attention.
- Using tools such as SAST, DAST, and Vulnerability Scanners earlier in the development pipeline gives developers more time to address critical issues such as insecure deserialization, potential server-side request forgery vulnerabilities, and security misconfiguration.
- Software updates should be thoroughly tested by both the development team and the end-user before they are installed on all endpoint systems.
- Effective threat modeling gives the development team a better understanding of the potential threats that the software will face and how the adversary will try to steal critical data.
Want to find out more integrity violations?
A hot topic for the year, there is plenty to read about in relation to data integrity failures, including these CWEs:
- CWE-494: Download of Code Without Integrity Check
- CWE-502: Deserialization of Untrusted Data+
- CWE-829: Inclusion of Functionality from Untrusted Control Sphere
As well as these helpful guides on learning how to improve your approach to coding (or convince your development team to make your job easier!) in a production environment:
