Security Flaws Common in Enterprise Applications

Nearly 32% of newly introduced enterprise applications are found to have flaws from the first vulnerability scan, according to new Veracode research.

In addition, by the time they have been in production for five years, nearly 70% of applications contain at least one security flaw.

After the initial scan, apps quickly enter a “honeymoon period” of stability, and nearly 80% do not take on any new flaws at all for the first year and a half, according to Veracode. After this point, however, the number of new flaws introduced begins to climb again to approximately 35% at the five-year mark.

Developer training, use of multiple scan types, including scanning via API, and scan frequency are influential factors in reducing the probability of flaw introduction, suggesting teams should make them key components of their software security programs. For example, skipping months between scans correlates with an increased chance that flaws will be found when a scan is eventually run. Furthermore, top flaws in apps vary by testing type, highlighting the importance of using multiple scan types to ensure hard-to-identify flaws aren’t missed.

With heightened focus on the software bill of materials (SBOM) over the past year, Veracode’s research team also examined 30,000 open-source repositories publicly hosted on GitHub. Ten percent of repositories hadn’t had a commit — a change to the source code — for almost six years.

Chris Eng is Veracode‘s chief research officer.

“Using a software composition analysis (SCA) solution that leverages multiple sources for flaws, beyond the National Vulnerability Database, will give advance warning to teams once a vulnerability is disclosed and enable them to implement safeguards more quickly, hopefully before exploitation begins,” he said. “Setting organizational policies around vulnerability detection and management is also recommended, as well as considering ways to reduce third-party dependencies.”

Mark Lambert is vice president of products at ArmorCode.

“As the software supply chain gets more complicated, it is critical to know what open source you are indirectly utilizing as part of third-party libraries, services (APIs) or tools,” he said. “This is where SBOM comes in. By requiring a disclosure of all embedded technologies from your vendors, you can perform analysis of those libraries to further assess your risk and react appropriately.”

Events like the Log4Shell vulnerability have highlighted the need and value of SBOM at the enterprise level, Lambert said. But for many, this has not yet translated to how development teams will be able to leverage them without slowing down software delivery with manual tasks.

“One of the big challenges I see is that this is more data for the development teams to manage as they deliver software,” he said. “Organizations are going to need ways to automate generating, publishing and ingesting SBOMs. They will need ways to bring the remediation of the associated vulnerabilities into their current application security programs without having to adopt whole new workflows.”