We’re not the first to admit that all these standards can get confusing—we had to brush up on the contents of all three for this article. So how can manufacturers address the discrepancies? How can they find out about new advances in the state of secure development outside these standards? One solution is to derive a common set of requirements from different standards and requirements. The manufacturer can provide this common set of requirements for the development process or product under design to the teams that are building the product or process.
The activity would review the various standards and generate a single output that has been interpreted by the organisation to meet the compliance needs. This is an activity we see many organisations perform, as evidenced by activity SR1.3, ‘Translate Compliance Constraints to Requirements’, in the Building Security In Maturity Model (BSIMM), a study examining the current state of software security in a variety of industry verticals. Note that SR1.3 is just one of 116 distinct activities measured by the BSIMM, intended to help organisations to build more secure software.
The BSIMM also includes other required activities. Take the examples of subject matter expertise and top management’s responsibilities. Those concepts are addressed in BSIMM activities T1.5 ‘Deliver Role-specific Training’ and CP2.5 ‘Ensure Executive Awareness of Compliance Obligations’.