Best practices for securing the software supply chain
In the wake of several highly publicized supply chain attacks, regulatory and media focus is shifting to address third-party software risk. The Department of Defense’s Cybersecurity Maturity Model Certification, established on January 31st, 2020, was the first attempt at creating a supply chain security compliance mandate. Only a few months later, threat actors infamously gained access to the build environment at SolarWinds and inserted a vulnerability directly into a security update that was then pushed to production. This combination of Insider Threat and Supply Chain Attack wound up compromising customers who installed the update, including US Federal agencies. In response to the growing threat of supply chain attacks, the Executive Order on Improving the Nation’s Cybersecurity established the Software Bill of Materials (SBOM) requirement. Whether for financial or political gain, threat actors are focusing on supply chain attacks. Software developers can prevent supply chain attacks by securing DevOps.
What is a supply chain attack?
In a supply chain attack, threat actors target a third-party service provider’s cybersecurity weakness, then use the vendor’s product to gain unauthorized access to the companies using the product or service.
A software supply chain attack can arise from any of the following services or products:
- Open-source or third-party code used in developing software
- Open-source platforms
- Business or technology partners collecting, storing, or processing data
- Cloud services providers
Threat actors might use a software vulnerability that enables them to deploy malware within a customer’s systems or networks. For example, in the SolarWinds supply chain attack, threat actors inserted malicious code into builds of the company’s Orion Platform. The threat actors then used this vulnerability to gain unauthorized access to the SolarWinds customers who installed the update. Most recent numbers indicate that the attack directly impacted 9 federal agencies and 100 private companies, and attackers continue to attempt attacks against Microsoft.
Supply chain attacks are becoming more prevalent. In the first quarter of 2021, the number rose by 42%, impacting 137 organizations across 27 different vendors.
What is the impact of a supply chain attack?
Supply chain attacks can have both short-term and long-term impacts. Additionally, these attacks hurt multiple business areas, not just the IT department.
Financial impact
The financial impact of a supply chain attack is likely the most obvious and newsworthy. For example, one 2017 data breach leveraging a software vulnerability cost a consumer credit reporting company an estimated $2 billion. More recently, threat actors used azero-day vulnerability against Kaseya, an endpoint management and networking technology vendor. Kaseya’s customers were predominantly Managed Service Providers who each had multiple end customers themselves. The threat actors were able to reach these end customers with a ransomware attack that impacted approximately 1,000 organizations, mostly small businesses. While this was a Supply Chain Attack, it is not considered an Insider Threat attack. But, researchers noted specifically that although the threat actors did not “deliver an implant with their exploit,” they could have.
Understanding the direct financial impact of a supply chain attack includes reviewing the following costs:
- Customer notification
- Legal
- Response
- Crisis management
- Business interruption
Compliance violations
Although compliance violations come with a financial impact, they also include operational costs. A supply chain attack often arises when a company fails to install a security update or fails to monitor security effectively.
The costs of compliance violations include:
- Penalties/fines
- Remediation
- Additional audits to prove continued compliance
Customer churn (reputation)
Everyone talks about the reputation risk associated with supply chain attacks, but quantifying the impact is often more difficult.
For example, a survey asked 1,000 customers whether they would still do business with a company after a breach. Respondents indicated after a data breach they would be less likely to maintain a consumer relationship with:
- Retail store: 58%
- Hotel chain: 80%
- Financial institution: 83%
- Social media site: 86%
- Rideshare service: 93%
How can supply chain attacks be prevented?
With threat actors focusing more intently on supply chain attacks, building security into the development process becomes mission-critical. Software developers need to embrace DevSecOps to prevent their applications from being used in a supply chain attack. They can do this by creating standards that ensure coding best practices, especially when third-party code is involved.
Engaging in due diligence
Part of establishing coding standards should be reviewing open source code prior to integrating it into an application. Developers need to treat open-source code like a third-party vendor. This means building due diligence into the process and reviewing open source code prior to using it.
As a best practice, teams should make sure that they:
- Create and maintain an inventory of all open source libraries used
- Note whether the code is used for internal or external projects
- Document how they plan to use the open-source component
- Review whether the repository owner provides security updates
- Review how often the owner updates the repository
By applying vendor risk management processes to code, the development team builds governance into their practices.
Monitoring third-party code
Whether securing their own or the open-source code, developers should continuously monitor their code. Although developers often worry that security testing will reduce their productivity, it is a fundamental supply chain attack prevention strategy.
Threat actors know about vulnerabilities as soon as, if not before, they are released to the public. If a team is using an open-source software (OSS) library with a known vulnerability, threat actors can use the weakness as a way to weaponize the application. Problematically, one report notes that only 23% of organizations engage in software vulnerability scanning in the build pipeline.
Developers need to incorporate static and dynamic assessments into their build processes to ensure continued security.
Prioritizing remediation
For developers, prioritizing remediation is often the most difficult part of securing the software development lifecycle. Not every vulnerability is actually or potentially exploitable. Developers need visibility into whether the vulnerability is reachable.
Software composition analysis (SCA) provides visibility into whether an application’s code calls an open-source library with known vulnerabilities and helps prioritize vulnerabilities. However, 39% of organizations wait to run SCA scans until the testing phase when remediation is more difficult and costly.
Teams should be looking for vulnerabilities and prioritizing remediation strategies as early in the development process as possible to enhance security and reduce overall costs.
Securing the DevOps Process Prevents Supply Chain Attacks and Reduces Costs
Building security into the software development process prevents supply chain attacks because developers remove the vulnerabilities before the application goes to production. Further, by continuously reviewing code during the build phase, organizations reduce costs.
Equally important, developers need visibility into whether a vulnerability poses an actual or potential risk. A first step is to determine whether the vulnerable code is being called or not, but this is not enough to determine “reachability”. Even if the code is called, the development team may have assembled it in a way that makes the vulnerability unreachable from the attack surface, so spending time to fix it leads to unnecessary development costs. Teams need to know how to focus their efforts so that they can deliver products on time.
By incorporating vulnerability monitoring and prioritization into the build phase, teams can meet deadlines and reduce risk. Developers can build security into their processes without reducing their productivity. ShiftLeft’s SCA and Static Application Security Testing (SAST) provide the speed and visibility that teams need.
We at ShiftLeft have been working on making open source security more manageable by helping you focus on exploitable open source vulnerabilities. Speak with us and we can help you assess your risks and recommend more efficient processes and procedures.
Top comments (0)