Thomas

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).

More and more standards, frameworks, and customer requirements demand – even cry out for – library management. They cry out because modern application development methods are completely dependent on external libraries, i.e., dependencies.

From the application developer’s perspective, this is fantastic – the world is full of practical helper libraries. Unfortunately, the world is also full of crap.

What is SCA?

Software Composition Analysis (SCA) is what’s known as a ‘Gartner term’ for library management. Another significant concept in this context is SBOM – software bill of materials. Both are practically the same thing, though the context may differ. When managing libraries, this is done, of course, automatically and with a good tool.

The decision to acquire a tool must be considered and evaluated. Tools are acquired for the sake of security, but sometimes it’s also good to recognize other business drivers. Hence, we will identify at least some of them next.”

Regulation - a beloved enemy

DORA and RTS (Regulatory Technical Standards)

DORA is a familiar but relatively new concept in the financial sector. It dictates the management of libraries as follows:

"The source code and proprietary software provided by ICT third-party service providers or coming from open-source projects shall be analysed and tested for vulnerabilities."

"Track the usage of third-party libraries, including open source, monitoring the version and possible updates"

ISO 27001:2022 Annex A (ISO 27002:2022)

The ISO standard calls for component management. This must be approached through risks – if you are involved in application development or if application development is significantly present in your business, this must be taken into account.

"If using external tools and libraries, the organization should consider:

a) ensuring that external libraries are managed (e.g. by maintaining an inventory of libraries used and their versions) and regularly updated with release cycles;

c) the licence, security and history of external components;"

IEC 81001-5-1 Health software and health IT systems safety, effectiveness and security

It can be noted that this (too) standard incorrectly uses the abbreviation SCA, and in the case of SCA, it actually means SAST.

"Static Code Analysis (SCA) for source code to determine secure coding errors using the secure coding standard for the supported programming language"

Under vulnerability management, however, the situation is corrected, and the concept of software composition analysis is used, but of course without the abbreviation at this point. The requirement, in any case, is clear.

"SOFTWARE COMPOSITION ANALYSIS on all binary executable files including embedded firmware, to be used with HEALTH SOFTWARE and delivered by a third-party supplier. This analysis can be used to detect: 2) linking to vulnerable libraries;"

ISA / IEC 62443-4-1 Security for industrial automation and control systems Part 4-1

SCA is not just for the IT world to enjoy, but the OT world also bears its share of the burden.

It can be noted that this (too) standard uses the abbreviation SCA incorrectly, and in the case of SCA, it actually refers to SAST.

"Static Code Analysis (SCA) for source code to determine security coding errors such as buffer overflows, null pointer dereferencing, etc. using the secure coding standard for the supported programming language. "

Under vulnerability management, however, the situation is corrected, and the concept of software composition analysis is used, but of course without the abbreviation at this point. The requirement, in any case, is clear.

"for compiled software, software composition analysis on all binary executable files, including embedded firmware, delivered by the supplier to be installed for a product. This analysis shall detect the following types of problems at a minimum:

1) known vulnerabilities in the product software components;

2) linking to vulnerable libraries;"

Veracode to the rescue!

To make it very clear at this point, Veracode and its SCA and SBOM tools are among the best on the market.

  • The sources of information are not only NVD and other public databases but also Veracode’s own research group. This ensures that there’s no need to wait for final and official vulnerability disclosures.
  • The tools fit into all known pipeline environments and can be used and automated as needed.
  • The tools are easily brought directly to the developer – meaning shift left also applies to libraries. An undesirable library gets caught before it even becomes part of the build.
  • Nasty licenses are brought under control.
  • SBOM listings are as easy as pie.

Of course, SCA is not the only capability of the Veracode platform. The platform offers the broadest selection of SAST, DAST and API scanning, as well as a hallucination-free and curated AI solution, Veracode Fix.

Veracode SCA - dependencies
Thomas

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).

contact us

Please do contact us. We most likely respond faster than you thought,