Managing risk in the software supply chain | Technology

The Building Security In Maturity Model (BSIMM) is a well-respected, in-depth set of activities businesses use to increase understanding of their cybersecurity risk management.

Despite the positive application of the BSIMM, its size can make it seem like a daunting tool. With this in mind, Synopsys introduced the BSIMMsc almost eight years ago. It has since undergone years of systematic refinement to help streamline risk management in the process of software acquisition from third-party vendors by keeping vendors accountable for their code. 

The BSIMMsc offers organizations a risk management tool that provides insight into vendors’ software security efforts through an attestation, designed for ease-of-use by groups that work to assess and minimise the risk of third-party software. The BSIMMsc offers a process to highlight risk for software acquirers, allowing them to glean insight into the software security efforts of specific vendors. This allows organisations to conduct an analysis of the software that vendors propose to deliver. In turn, this promises to provide a significant innovation from the outdated methods of quality assurance, such as simply reviewing a vendor’s penetration test reports, while reducing the inconvenience of commissioning an external or in-house penetration test on commercial off-the-shelf software or any other software provided.

Cutting out clueless code

Following nearly eight years of real-world scenarios, two primary uses for the BSIMMsc surfaced. The most frequent applications of the BSIMMsc are to assess the reliability of software vendors. This can be described informally in binary terms, with the vendors grouped based on their reliability as either “clueless” or “clueful”. This is essential to daily business operations because conducting business with a clueless vendor can have serious security consequences. The BSIMMsc provides additional scrutiny in the software procurement process as it affords the ability to sort vendors according to how seriously they take software security. This facilitates the creation of a “do not buy from” list, which both significantly limits the possibility of conducting business with clueless vendors when decision-makers are searching for new software, and actively increases cybersecurity awareness. 

A further use of the BSIMMsc is to separate clueful prospective vendors into two additional groups. One group consists of vendors that display immature security processes, resulting in software that occasionally passes penetration tests (but usually doesn’t). The second group will have the software security fundamentals required for consistently generating high-quality software and are well known for facilitating a quick response when necessary. This information can directly inform a “preferred vendor” list. Over time, vendors will strive to move from the “don’t buy” to the “preferred” list, increasing software quality for all acquirers.

The BSIMMsc operates through a qualitative approach, providing a very effective, low-impact initial look into software security capability. Indeed, if a prospective vendor fails this brief critical review then it clearly indicates that they are not worth the time and money to conduct a deep-dive quantitative analysis. Furthermore, because of the nature of enterprise risk management, the BSIMMsc is intentionally streamlined in terms of scope and power in order to maintain user engagement.

SEE ALSO:

What’s in your code?

Given the constantly increasing complexity of corporate software environments, it is no surprise that firms are increasing scrutiny of software security, particularly when considering the ubiquity of third-party software. Indeed, every modern enterprise relies on third-party software in some manner, especially considering constraints such as imposed time-to-market deadlines and technology stacks. Third-party code can manifest in several forms from custom-built software to software-as-a-service. Some external code, such as JavaScript modules, is inevitable as vendors and partners often inject it into a firm’s web applications to provide added value for the firm or its customers. Some external software even possesses the capability to write new code as it executes. As third-party code is so prolific, it is important to understand what your company relies on, and why. Putting your faith in the wrong vendor or vulnerable code might have catastrophic consequences. Therefore, the BSIMMsc is a valuable tool for identifying reliable vendors. You wouldn’t put something you don’t trust into your body, so why imbed it into your business? 

Understanding what third-party software an organisation employs can be a challenge, making software risk analysis an extremely difficult task. To mitigate this risk, the BSIMMsc focuses explicitly on providing a lightweight indictor of a vendor’s security capability, instead of attempting to measure the security posture of a particular piece of software. By simply measuring software after it has been delivered, firms are often measuring their own ability to test software rather than the vendors’ ability to consistently make good software, leading to inadequate risk management. Determining which fundamentals of software security specific vendors prioritize will provide a more cohesive understanding of associated risk when compared to a simple penetration test.

What’s important?

Following ongoing discussions within the wider BSIMM community, several activities appear to be broadly prioritised. Software vendors and acquirers consider the following pieces of evidence to provide an adequate initial gauge of third-party software security capability:

• A documented, secure software development lifecycle (e.g., an SSDL that includes security checkpoints)

• Artefacts showing that the activities described in the SSDL occur as expected (e.g., the results from an architecture risk analysis or a code review)

• Personal conversations with the software security leader that demonstrate a high level of knowledge about software security initiatives and technology

• The existence of a full-time software security group (SSG), perhaps called a product or application security group

• A documented process that ensures security defects are addressed and fixed

• A third-party review of software security efforts and results 

With this feedback from industry professionals in mind, the BSIMMsc was designed to encompass three design requirements.

Firstly, it shall be explicit and clear about real software security activities. Secondly, it shall discriminate between firms that know little about software security and firms that practice some of the basics. Finally, it shall help assess maturity in a way that coheres with the larger BSIMM. This keeps software vendors accountable for their products and encourages greater transparency between acquirers and vendors.

The BSIMMsc offers the potential to gauge vendor software security efforts by analysing metrics across four industry-specific domains: Governance, Intelligence, SSDL Touchpoints, and Deployment. Within these domains, the BSIMMsc isolated 22 (out of 119) security model activities that outline the maturity of a vendor’s software security development. 

For more information on how to keep your code safe, read the latest BSIMMsc whitepaper by Synopsys.

By Sammy Migues, BSIMM Co-Author and Principal Scientist at Synopsys.