The best way to solve the software security risk problem is when and where it starts, right at the software creation or as close to the beginning as possible. Solving the problem after the software is written, tested and deployed is like testing and fixing cars after they left the car manufacturing facility. Fortunately, the industry hasalready realized this and started integrating security controls and checks early on in the software development lifecycle.
Shift Left – Developer Centric
Shift security left is a practice that is intended to find and fix security issues early in the software development lifecycle. The first few iterations of this practice were a Waterfall-ish. For example, OWASP’s version of pushing security left and adding security earlier into the software development lifecycle is OpenSAMM (https://www.opensamm.org/).
OpenSAMM defines 12 security practices divided among 4 business functions. You can see right away how the model 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. For Agile development teams, particularly with DevOps practices this would be challenging to implement.
At reshift security we believe that the main reason companies don’t really have a grip over the software security problem, is not the lack of interest by the software developers as many would believe. We believe that the lack of developer-centric solutions is the main problem. If you look at the software security problem and getting developers to embrace shipping more secure code as a “change”. Developers adopted and promoted several changes before: “API First”, “Cloud”, “Serverless” to list a few. Software developers are a smart breed that solves 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 these tools to work for developers.
How Developer-Centric Solutions are Different:
- Properly shifting security left: shifting security left means integrating security practices early on in the software development lifecycle. According to a research done after Google’s attempt to integrate classic static code analysis tools into their SDLC, a survey has been on the developer’s 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.
- Seamless integration into developer’s workflow: most security tools do integrate into developers workflow. Some integrations are shallow and some other integrations are not. Most security tools offer some integration into the developer’s tools and workflows, perhaps a IDE plugin or some form of integration into the build process. A seamless integration into the 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 a different than what they are normally using but somehow they are writing more secure code.
- Developer features: speed, accuracy and usability are features that security tools are not really great at.
Speed: as discussed before, the speed of software development has gone from months to hours and sometimes minutes. If security is going to prevent the developer from maintaining this speed, it is probably going to be rejected by them.
Accuracy: developers have very low tolerance to false positives. While security engineers look at findings as potential issues, developers look at them as noise.
Usability: developers appreciate smart and usable tools, because of their craft they come across a lot of tools and usability best practices.
Ready to get started?
reshift is a light-weight code security tool built for developers to code securely, fix quickly, and deploy fast.