CA Southern Africa has revealed details of the 2023 Veracode State of Software Security report into the factors that introduce flaws in application development, one of which the research notes is the great unknown of open source.
The report notes that developers build their applications using libraries completely outside their control, establishing dependencies for basic functions that an application needs.
Some of these dependencies then introduce further dependencies. This continues through to the top three items in this discussion, namely flaw introduction, technical debt accumulation and lifecycle management.
Craig de Lucchi, account director at CA Southern Africa, says for the purposes of this report, Veracode took steps to analyse and profile open-source repositories.
“The report notes that not reinventing the wheel has obvious rewards, but open source is not free. It cedes control and introduces external dependencies. For each publicly disclosed vulnerability, one can only speculate how many undisclosed and undiscovered vulnerabilities there really are waiting to hit the news and launch us all into the next panic,” says de Lucchi.
Aside from scattergun technical controls and Herculean response tactics, what steps can organisations take to reduce their exposure and improve their response if they are affected?
Veracode implemented the concepts of “the Bus Test”.
“In terms of business continuity management/disaster recovery (BCM/DR), when risk comes up, the bus test comes out,” de Lucchi says. “This is how it works: how many people must be hit by a bus in order to stop a project completely? That’s the bus test number. Or you can substitute other paradigms for the same results. For example: vacation; attrition; promotion. Pick your project title. In the interim, there are steps you can take to reduce the risk posed by open-source libraries.
Recommendations for Open Source, according to the report, include:
* Prioritise your efforts by looking at vulnerable methods, analyses, and the existence of public exploits. Consider that it might take weeks or months for a vulnerability to appear in the National Vulnerability Database (NVD) and how much advance warning means to your team. Any SCA solution in use should leverage multiple sources for flaws (not just NVD) to give advanced warning to teams. Once a vulnerability is disclosed (even via unofficial channels), it’s a race against the clock to when active exploitation begins. It might take weeks to months for a vulnerability to appear in the NVD, and by then, in-the-wild exploits may have already begun.
* Set an organisational policy around what vulnerabilities you’re willing to accept, understanding that different applications will have different risk profiles and risk tolerances. It’s more sustainable to enforce policy programmatically than trying to maintain an internal repo of “safe” libraries, which can be too resource intensive for all but the most well-staffed businesses.
* Consider ways to reduce your third-party dependencies. Think back to 2016 and the left-pad package6 that was 11 lines long. For simple “shortcut” code that is included by default, ask why it is included. Especially if it introduces new dependencies that are required in order for your code to work. If developers can write the code easily, and it’s low risk to do so, then try to reduce dependencies that can introduce fragility, or worse, increase your attack surface.