The BSIMM Community is made up of many different kinds of firms: firms that primarily acquire software, firms that primarily build and sell software, and firms that do both. Those BSIMM firms interested in promulgating software security among their software vendors are spearheading a software security vendor control model called vBSIMM. The vBSIMM project is concerned with measuring large numbers of vendors in order to assess SSDL maturity and control risk.
vBSIMM (BSIMM for vendors)
Every modern enterprise uses lots of third-party software. Some of this third-party software is custom built to specifications, some of it is COTS, and some lives in the cloud as part of a software-as-a-service (SaaS) model. Many big firms, especially in the financial services vertical, are working hard on software security and are looking for ways to identify and manage the risk of third-party software.
Vendor Control in the BSIMM: Measuring Yourself
The BSIMM includes five specific activities (out of 111) that are relevant to controlling the software security risk associated with third-party vendors. These are worth calling out because they are activities that should be performed by all firms acquiring third-party software. They are:
- Compliance & Policy activity 2.4: Paper all vendor contracts with SLAs compatible with policy.
- Compliance & Policy activity 3.2: Impose policy on vendors.
- Standards and Requirements acivity 2.1: Communicate standards to vendors.
- Standards and Requirements activity 2.5: Create SLA boilerplate.
- Training 3.2: Provide training for vendors or outsource workers.
Every firm that acquires third-party software (whether custom, COTS, or anything in between) should take the time to determine how well they are performing these five activities with each supplier.
Using a Lightweight BSIMM derivative for Vendor Control
We introduce a completely-revised compact version of the BSIMM for vendors called vBSIMM in an informIT article vBSIMM Take Two (BSIMM for Vendors Revised). You can think of vBSIMM as a foundational security control for vendor management of third-party software providers.
The vBSIMM scheme is far from perfect and it does nothing to guarantee that any particular vendor product is actually secure enough for all uses. The vBSIMM scheme is far superior to no vendor control at all, however, and in our opinion is much superior to a badness-ometer-based approach using after-the-fact penetration testing focused only on a handful of bugs.
Here is a simple attestation form for use with the vBSIMM [.doc].