The best way to solve the software security problem is when and where it starts, right at the software creation phase. Solving the problem after the software is written and deployed is like testing and fixing cars after they left the car manufacturing facility. Fortunately, the industry has already realized this and started integrating security controls and checks early on in the software development lifecycle.

Securing the Software Development Lifecycle

The first few iterations of securing the software development lifecycle focused on adding isolated activities to the software development organization. When these first few iterations came out, it was a time when most organizations were following a waterfall methodology.

One of the popular methodologies to integrate security into the Software Development Life Cycle is OpenSAMM ( defines 12 security practices divided among 4 business functions: Governance, Construction, Verification and Deployment. OpenSAMM goes afterward and describes 3 security practices with each business function.

  1. The Governance: a business function includes performing the following security activities: Strategy & Metrics, Education and Guidance, Policy & Compliance
  2. The Construction: business function includes performing the following security activities: Security Requirements, Threat Assessment and Secure Architecture
  3. Verification: a business function includes performing the following security activities: Design review, security testing and code
  4. Deployment: a business function includes performing the following security activities: Environment hardening, vulnerability management and operational enablement

SAMM Overview


You can see right away how the methodology makes the assumption that the business functions are nicely segregated from each other. OpenSAMM would work great for organizations that are working using Waterfall methodologies. Another popular methodology is Building Security In Maturity Mode (BSIMM), a popular methodology used by organizations like CapitalOne, Verizon and FreddieMac. Similar to OpenSAMM, the BSIMM framework consists of 12 practices organized into four domains: Governance, Intelligence, SSDL touchpoints and Deployment.

Building Security In Maturity Mode (BSIMM)

While BSIMM and OpenSAMM focus on integrating multiple security controls into the software development lifecycle (SDLC). Several challenges exist coming to implement these frameworks:

  1. Most of the time these activities are actually implemented by security teams, making it harder for developers to get onboard.
  2. A significant overhead is being added to the whole process to integrate security in, making it slower and more expensive to ship software.
  3. Silos between security and development teams add to the challenge of successful integrating security into the development process  

As Brent Midwood puts it perfectly in his article; Security & Development: Better Together

“To be clear, DevOps practices plus security practices does not equal DevSecOps. Rather, DevSecOps is delivery of security as code”

Brent Midwood

The world of software development where a waterfall methodology dominates and isolates teams working in silos is long gone.

Developer-Centric Solutions

Some of the most innovative companies today like Facebook, Google, and Amazon pride themselves in being developer-centric cultures. Developer-centric cultures are more attractive to top engineering talent, one that provides them with mastery, autonomy and purpose is key to building strong engineering cultures. There are several definitions for a Developer-centric culture, but one of the best we heard is

“In a “Dev Centric” culture the developer is responsible throughout the product lifecycle, from product definition to maintaining it in production.”

“In a “Dev Centric” culture the developer is responsible throughout the product lifecycle, from product definition to maintaining it in production.”

Communication of the ACM

At reshift security we believe that the main reason companies don’t really have a grip onr the software security problem, is not the lack of interest by the software developers, but rather the lack of  developer-centric security solutions. 

Looking at our existing software security problem, getting software developers to embrace shipping more secure code it is often seen as a big “change”. 

Developers have adopted and promoted several changes before; “API First ”, “Cloud”, and “Serverless” to list a few. Software developers are a smart breed that solve problems for a living. I see a kiss of death when organizations force the solutions that worked for security audit teams, down onto developers and expect them just to adopt those tools and accept that they work for developers.

How Developer-Centric Security Solutions are Different:

  • Developer tailored education: developers are not security experts, they need documentation built for them and how they consume information. Bridging the knowledge gap within the tool is paramount for developers to succeed with security.
  • Pushing security all the way left: According to research from Google’s attempt to integrate classic static code analysis tools into their SDLC, a survey shows developers’ perception of the issues found depending on when the issues are introduced to them. 74% of the issues flagged at compile time as “real problems,” compared to 21% of those found in checked-in code.

”This result is explained by the "survivor effect"; that is, by the time code is submitted, the errors are likely to have been caught by more expensive means (such as testing and code review). Moving as many checks into the compiler as possible is one proven way to avoid those costs.”

Communications of the ACM
  • High accuracy detection: developers have a very low tolerance for false positives,  their main task is to ship new code, chasing false positives does not appeal to busy developers. Often people will compare security issues to quality issues and try to make the case that they should be treated as quality issues. However, there is a big difference, quality issues usually enter the bug tracking system when there is evidence; i.e. unit tests generated the bug, client reported it or a quality assurance engineer discovered it. Compare that to a tool-generated security issue, with no evidence other than the “tool said so”. So accuracy is obviously very important
  • Automated remediation: finding vulnerabilities is only half the battle, tools that just find issues are seen by developers as more busy work. During Google’s 3rd attempt to integrate regular static code analysis into their process, that particular attempt was focused on submitting the results directly into the code review process as comments, the approach was then stopped as developers saw this to be more of noise than anything else.

Once Google started sending “Fixes” instead of just “Bugs”, developer’s engagement increased dramatically.

"57% of the developers who received a proposed fix to checked-in code were happy to have received it, and 41% were neutral. Only 2% responded negatively, saying, "It just created busywork for me."

Communications of the ACM

Seamless integration into developer’s workflow: most security tools do integrate into developers workflow. Some integrations are shallow and other integrations are not. Most security tools offer some integration into the developer’s tools and workflows, perhaps an IDE plugin or some form of integration into the build process. A seamless integration into development is more than IDE plugins and build integrations. Seamless integration into the developer process is one where the developer almost does not feel they are using anything other than their normal tools, yet somehow they are writing more secure code.