Dev + Sec + Ops != DevSecOps
Dev + Sec + Ops ! = DevSecOps
Historically, security vendors and code scientists around the world have been looking for a single universal formula to represent the notion of DevSecOps.
In my previous posts, I had introduced ShiftLeft Scan and written about the cultural and process changes involved in transitioning from DevOps to DevSecOps (For an intro to Scan please join our webinar on April 30th). This post is about implementing application security correctly so that your DevSecOps doesn’t incorrectly look like three independent things that are weakly glued up (Dev + Sec + Ops is not DevSecOps). What do I mean by this?
A common flaw with AppSec implementations
Let us assume a product team that consists of three people — a developer (Dev), a sysadmin (Ops), and a security analyst (Sec). This team like any would go through the 4 stages of team formation. Over time, the behavior of the team might resemble this:
Developer: This person would be considered the doer because they develop and do the things required by the business.
Ops: If anything doesn’t work it is the Ops’ fault!
Security: If this person does their job well, then the developer, ops, and the business would wrongly tag them as the only person in the team who always delays or blocks the delivery or the release. People are never fans of testing especially testing that takes time and resources. Over time, this person would be so detached that they would either stop contributing ideas or work in an isolated fashion doing the bare minimum required.
What will happen if we now replace the security personnel with a tool? Nothing would change really. The tool would be considered as a blocker. Whatever the tool finds will be pushed to the backlog with an exceptionally low priority. If the tool gets mandated by the CISO, then friction would develop between the product and security teams.
When security gets bolted onto the development process instead of getting embedded into it, then DevSecOps starts to fail.
So, the real question is how do you embed security entirely into the development workflow?
Embedding security into the development workflow
Before talking about workflow, it is important to understand the various cognitive processes and activities that constitute a development phase.
As shown, the development process can be fundamentally broken down as:
Plan phase: This is the phase where the developer/team thinks and researches about the upcoming work. They could be investigating libraries and packages, or the logic required to satisfy the requirements. A security tool could help them from this process onwards — by checking the library for known vulnerabilities and by assessing the business logic for known security flaws.
Code phase: This is the phase that is usually considered as development although this is only a small part. Security tools can help developers write secure code during this phase by being integrated with their IDE of choice. Git branching model requires a discussion on its own (following section) and is usually an area where the security tools do an average job, unfortunately.
Review phase: In this last but the most important phase, security tools should co-exist and review the work as a skilled developer would do. The tools should obey the same laws and rules regarding productivity, quality, and commitment. For example, the tools cannot take ages to review a PR. The quality of the findings should help rather than hinder the development work.
Even the language used by the tool is important. It should encourage a positive response from the developer and not blame them for the issues found. A great automated PR experience would resemble the helpful prompts provided by JARVIS to Tony in Iron Man movies. Useful and timely feedback that doesn’t block Tony from performing his work.
Security with Git Branching models
Development teams adopt a git branching model that suits their style and needs. Even within the same organization, a range of models would exist across teams and even within the same team but across applications. If you are new to the branching models on git, a good place to start is the Atlassian article here. Read on once you are comfortable with the models to understand the ideal anchor points for application security tools.
Trunk-based development
Scanning every commit is the easiest form of starting with any application security tool.
Commits can be scanned either via a git hook in the laptop or as a build step in the CI pipeline. Automatic build failures along with a repo badge can be used as an indicator of the quality of the master branch at any point.
Feature-branch development
This workflow is quite popular among established teams where each feature gets developed independently in its branch.
The best integration point for security in this model is the pull request (or merge request) flow. For teams that constantly suffer from issues related to long-running branches — the first advice would be to try to rectify the problem obviously. But as an intermediate workaround, additional scanning can be introduced as part of certain activities such as rebase from the master branch. This would ensure that vulnerabilities that already exist in the master branch are identified sooner and appropriate steps are taken to address them without affecting the development work happening in the specific branch.
Gitflow-based development
Gitflow model is quite popular among enterprise teams with an outsourced/supplier driven development.
Due to the additional branching requirements involved in this model, there is often a delay between a pull request getting merged into a development branch to an actual release and synchronization with the master branch. It is therefore essential to perform the scan during both the pull request and release process. To reduce the chances of building security debt over time such teams should also consider mandating an IDE-based security scanner.
Embedding security into the ops workflow
Work performed by the operations (ops or DevOps) can be categorized into:
- Configuration
- Automation
- Optimization
Security tools can also get embedded into this process by scanning the configuration and automation scripts for credential leaks, improper configuration of cloud resources (public s3 buckets or firewall), and security best practices in general. A next-generation tool could also help mandate security as code by providing libraries and hooks for popular infrastructure automation languages. Even operations and DevOps team would benefit from an IDE-based security scanner since fixing infrastructure vulnerabilities during development are cheaper and better. A good SAST tool can help you here too. It is better to detect infrastructure vulnerabilities during development. Otherwise, detection and remediation of insecure and vulnerable deployments would require expensive penetration testing and cloud-endpoint protections which are expensive to procure and even rollout.
Fixing infrastructure vulnerabilities during development is cheaper and better. A good SAST tool can help you here too
Closing thoughts
A good DevSecOps implementation would embed security into both dev and ops to such an extent that security would no longer be separable. A good security platform such as ShiftLeft is built specifically for this purpose and battle-tested in the real world across several organizations — large and small.
To learn more about how we help multiple Fortune 100 organizations implement and adopt DevSecOps tools and process, do not hesitate to contact us.
Dev + Sec + Ops != DevSecOps was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Prabhu Subramanian. Read the original post at: https://blog.shiftleft.io/dev-sec-ops-devsecops-5d05e3516e00?source=rss----86a4f941c7da---4
