FINAL WORD
process and technology considerations that help firms maintain the desired pace of innovation , securely .
In fact , the right managed security testing solutions will provide the ability to invert the relationship between automation and humans , where the humans powering the managed service act out-of-band to deliver high-quality input in an otherwise machinedriven process , rather than the legacy view in which automation augments and / or complements human process .
It also affords organisations the application security testing flexibility required while driving fiscal responsibility . Organisation gain access to the brightest minds in the cybersecurity field when you need them and not paying for them when you don ’ t ; you simply draw on them as needed to address current resource testing constraints . This results in unrivaled transparency , flexibility and quality at a predictable cost plus provides the data required to remediate risks efficiently and effectively .
Enact an open source management strategy
And we must not neglect the use of open source software ( OSS ) – a substantial building block of most , if not all modern software . Its use is persistently growing and it provides would-be attackers with a relatively low-cost vector to launch attacks on a broad range of entities that comprise the global technology supply chain . Open source code provides the foundation of nearly every software application in use today across almost every industry .
As a result , the need to identify , track and manage open source components and libraries has increased exponentially .
License identification , processes to patch known vulnerabilities and policies to address outdated and unsupported open source packages are all necessary for responsible open source use . The use of open source isn ’ t the issue , especially since ‘ reuse ’ is a software engineering best practice ; it ’ s the use of unpatched OSS that puts organisations at risk .
The 2020 Open Source Security and Risk Analysis ( OSSRA ) report contains some
Adam Brown , Associate Managing Security Consultant , Synopsys
concerning statistics . Unfortunately , the time it takes organisations to mitigate known vulnerabilities is still unacceptably high . For example , six years after initial public disclosure , 2020 was the first year the Heartbleed vulnerability was not found in any of the audited commercial software that forms the basis of the OSSRA report .
Notably , 91 % of the codebases examined contained components that were more than four years out of date or had no development activity in the last two years , exposing those components to a higher risk of vulnerabilities and exploits . Furthermore , the average age of vulnerabilities found in the audited codebases was a little less than 4½ years . The percentage of vulnerabilities older than 10 years was 19 % and the oldest vulnerability was 22 years old . It is clear that we ( as open source users ) are doing a less than optimal job in defending ourselves against open source enabled cyberattacks .
To put this in a bit more context , 99 % of the code bases analysed for the report contained open source software , of those , 75 % contained at least one vulnerability and 49 % contained high-risk vulnerabilities .
If you ’ re going to mitigate security risk in your open source codebase , you first have to know what software you ’ re using and what exploits could impact its vulnerabilities . One increasingly popular way to get such visibility is to obtain a comprehensive bill of materials from your suppliers ( sometimes referred to as a ‘ build list ’ or a ‘ software bill of materials ’ or ‘ SBOM ’).
The SBOM should contain not only all open source components but also the versions used , the download locations for each project and all dependencies , the libraries to which the code calls and the libraries to which those dependencies link .
Modern applications consistently contain a wealth of open source components with possible security , licensing and code quality issues . At some point , as that open source component ages and decays ( with newly discovered vulnerabilities in the code base ), it ’ s almost certainly going to break – or otherwise open a codebase to exploit .
Without policies in place to address the risks that legacy open source can create , organisations open themselves up to the possibility of issues in their cyber assets that are 100 % dependent on software .
Organisations need clearly communicated processes and policies to manage open source components and libraries ; to evaluate and mitigate their open source quality , security and license risks ; and to continuously monitor for vulnerabilities , upgrades and the overall health of the open source codebase .
Clear policies covering introduction and documentation of new open source components can help to ensure control over what enters the codebase and that it complies with company policies .
There ’ s no finish line when it comes to securing the software and applications that power your business . But it is critically important to manage and monitor your assets as well as to have a clear view into your software supply chain .
No matter the size of your organisation , the industry in which you conduct business , the maturity of your security programme or budget at hand , there are strategies you can enact today to progress your programme and protect your organisational data and that of your customers . •
76 INTELLIGENTCIO www . intelligentcio . com