For enterprise security teams, the accelerated pace of software development and the proliferation of software security tools have created both headaches and opportunities. The Building Security In Maturity Model (BSIMM) study illustrates how organizations with mature security programs transformed the results they get from security tools into key inputs that inform program management and improvement. While each organization follows its own path to maturity, the BSIMM highlights four common markers present in these mature firms that an organization can emulate to build a successful software security program.
Inventory Software Assets
The journey starts with organizations understanding what they are managing. For many organizations, this requires a new or additional effort to create a living software inventory.
Even mature firms struggle with keeping an accurate, current inventory that contains the information needed to make risk management decisions. While it’s good to track software characteristics (e.g., language, architecture, risk classification, data classification), it is becoming increasingly important to track composition (e.g., open source, third party, subcomponents).
While the BSIMM activity “develop an operations inventory of software delivery value streams” was only observed in nearly half (48%) of the 128 firms in the BSIMM12 study, it is regarded as a key to success. A well-running software security program must understand its portfolio.
Survey Telemetry Sources
Most organizations in BSIMM12 (71%) have defined a software security life cycle for managing their purview. Over the past two years, we have seen the number of BSIMM activities in the life cycle performed through automation greatly increase. One such example is “integrate opaque-box security tools into the QA process,” which has increased by 50%. These efforts are a great source of telemetry to feed decision-making processes.
While sources might produce important bug data, there is an often-underused selection of metadata available. For example, which projects have been scanned at what point of time using which methods provide three separate dimensions to create a more accurate risk management picture. When identifying telemetry sources, look further than what security tools are available.
Remember, automation is no longer just responsible for identifying vulnerabilities; in many cases, it is feeding go/no-go decisions, aggregating data, or managing risk exception processes. Each organization must survey what sources of data are available and plan for any areas where they are deficient.
Connect Tools; Establish Feedback Loops
To keep up with development velocity, many organizations are decomposing large, monolithic gates into smaller phases. This commonly replaces in-band manual exercises, like penetration tests, with one or more lighter, automated in-band equivalent activities. Heavier, manual exercises might still be performed but are done out-of-band. The output of these efforts and the telemetry sources from the last step feed dashboards that are published throughout the organization.
Modern dashboards focus less on vulnerability trends and more on business enablement, such as speed (execution and remediation) and quality (defect density and resiliency). These views of the data can help with bottom-up initiatives by spurring friendly competition among engineering teams. They also help with top-down initiatives by providing business leaders data to decide where to focus headcount or budget.
Drive Governance Decisions into Code
The most mature organizations are going one step further and are making governance decisions in code executed in pipelines. While the activity “integrate software-defined lifecycle governance” has grown, it was observed in only 4.6% of firms in the BSIMM12 study. Standards, policies, assessment spreadsheets, and other traditional governance management artifacts are being translated into Python scripts. This repeatable, efficient approach allows organizations to ensure adherence to security requirements while greatly accelerating proof of compliance.
While we cannot predict the future, we are confident that, as more automation is applied to application life cycle management, software security programs will be expected to make and manage decisions in code. This approach will require the infrastructure to understand the program’s portfolio, connect processes and tools in a deeper way, and push decisions and data so humans can review.
Your organization might be on different steps of this journey. You might need to re-evaluate previous steps to advance, but this journey is key to solving tomorrow’s problems.
Source: www.darkreading.com