Even when your organization relies heavily on third-party software, you’re still responsible for making sure that software meets security expectations, adheres to compliance requirements, and protects customer data.
Even when your organization relies heavily on third-party software, you’re still responsible for making sure that software meets security expectations, adheres to compliance requirements, and protects customer data.
We previously introduced a compact version of the BSIMM for vendors, called the vBSIMM. Now we’ve released a new version: BSIMMsc. The BSIMMsc describes a set of activities that you can use as part of your software supply chain risk management strategy. It empowers you to measure the software security capabilities within a supplier’s software development process.
BSIMM9 includes five specific activities (out of 116) that are relevant to controlling the software security risk associated with third-party vendors. These are worth calling out because they should be performed by all firms acquiring third-party software:
Every firm that acquires third-party software (whether custom, commercial off-the-shelf, open source, or anything in between) should take the time to determine how well they’re performing these five activities relative to each software supplier.
The BSIMMsc comprises the following BSIMM activities:
BSIMM Practice |
Identification & Response |
Integration & Governance |
Depth & Automation |
Strategy & Metrics |
SM1.4 |
SM2.2 |
|
Compliance & Policy |
CP1.3 |
|
|
Training |
T1.5 |
|
|
Standards & Requirements |
SR2.4 |
|
|
Architecture Analysis |
AA1.4 |
AA1.1 |
AA1.2 |
Code Review |
CR2.7 |
CR1.2 |
CR1.4 |
Security Testing |
ST1.1 |
ST1.3 |
ST2.1, ST2.6 |
Penetration Testing |
PT1.1 |
PT1.2 |
PT1.3 |
Software Environment |
SE3.6 |
|
|
Config. Mgmt. & Vuln. Mgmt. |
CMVM1.1 |
CMVM1.2 |
CMVM2.2 |
Use the model to review the software security maturity of any software supplier.
Based on a risk ranking of the software itself and the findings from your vendor assessment, you can then put their software to the test. As appropriate, you might use approaches such as static analysis (SAST), penetration testing, architecture risk analysis, dynamic application security testing (DAST), and fuzzing.