Mid-market organizations face the same security, regulatory, and compliance requirements as their larger peers without the same resources. Security resources are scarce. Synopsys’ BSIMM12 report found that the average Software Security Group member supported over 140 developers and 43 applications. Mid-sized and emerging enterprise organizations often lack any employees devoted exclusively to software security. 

Integrating security into a rapid development methodology can be difficult for any size organization. As small and mid-sized organizations continue to adopt a DevOps approach to developing and releasing software faster, these security challenges can become more pronounced.

“Shifting left” refers to the practice of moving security earlier in the development process. Anticipating security issues during the requirements and design phases of the software development life cycle (SDLC) allows developers to build in appropriate controls and avoid security surprises later in the process. This saves time and money. A study by the IBM System Science Institute found that fixing issues found in testing cost 15 times more than if that defect was identified in design. Those errors found in the maintenance phase of the development lifecycle cost 100 times more!

 It is clear that shifting left is beneficial to organizations – especially when time to market is critical. That’s where DevSecOps comes in.

What is the Difference Between DevOps and DevSecOps?

DevOps combines practices, tools, and culture to improve an organization’s ability to deliver quality applications and services at high velocity. It started as a means to decrease organizational silos and bring development and operations teams together around shared goals.

What is missing from this teaming, of course, is security. A faster development process can lead to coding errors that result in vulnerabilities. But security weaknesses can also come into play through insufficient security requirements, design flaws, incomplete or missing testing, or operational errors like misconfigurations and use of default credentials. The move to cloud hosting also presents challenges, as the security controls for cloud deployments are different from on-premises deployments (and unfamiliar to many teams). If security remains a siloed “service” tasked with finding weaknesses in software after it is developed, high velocity and quality are unattainable.

DevSecOps addresses this by integrating security at every phase of the SDLC, from initial design through integration, testing, deployment, and delivery. As defined by the Cloud Security Alliance, DevSecOps is “The integration of continuous security principles, processes, and technologies into DevOps culture, practices, and workflows.”

Secure the Software Factory

DevSecOps has use cases beyond writing more secure code faster. For example, the SolarWinds breach didn’t occur because the development team neglected to test their developers’ code. The compromise of their Orion application happened because they had insecure build operations. More advanced DevSecOps practices such as reviews of developer access, pull requests, and commit size could have helped identify malicious activity.

The Six Pillars of DevSecOps

For organizations initiating or maturing their DevOps programs to adopt DevSecOps, the Cloud Security Alliance (CSA) offers useful guidance in their publication “The Six Pillars of DevSecOps.” The pillars provide a holistic framework that blends the traditionally siloed operations of development, infrastructure operations, and information security, into a cohesive group that facilitates the rapid development of secure software.

Pillar 1.    Collective Responsibility – Every person in the organization has responsibility for security and an obligation to understand their contribution to the organization’s security stance.

Pillar 2.    Collaboration and Integration – Siloed organizations cannot achieve speed and security. Collaboration around implementing security reduces friction between development, security, and operations.

Pillar 3.      Pragmatic Implementation – Every development life cycle is different. Attempting to implement DevSecOps through one-size-fits-all tools can be difficult to operationalize. Teams require framework-agnostic a “Digital Security and Privacy Model” and actionable insights.

Pillar 4.      Bridging Compliance and Development – Identify compliance requirements and translate them into appropriate software measures that can be implemented by development, security, and operations personnel.

Pillar 5.      Automation – Avoid manual processes whenever possible. Automate software quality checks to increase efficiency and reduce rework.

Pillar 6.      Measure, Monitor, Report, and Action – Identify and track critical metrics such as deployment frequency, mean time to fix, and the percentage of code that is automatically tested.

SD Elements and the Six Pillars of DevSecOps

Not every company has extensive security resources. SD Elements helps growing companies scale their application security programs with a flexible platform that helps anticipate weaknesses in software and translate risks into actionable mitigation controls.

Next Steps

DevSecOps requires that organizations understand potential security issues and implement controls at a rapid pace. SD Elements helps development, security, and operations collaborate by translating potential weaknesses and assigning them to individuals as actionable controls – including code samples, test plans, and training courses. It integrates with leading DevOps tools, issue trackers, and security testing tools so everyone understands their responsibilities and the security profile of an application at any time.

To learn more about SD Elements and its ability to automate and scale threat modeling for DevSecOps, read our whitepaper or contact us.