Nuanced or real?
To some, the difference between Dev-first-AppSec and DevOps-first-AppSec feels like a nuance. After all, the line between developers and DevOps is somewhat blurry, and by extension, it may not seem like a significant difference, whether application security is targeted at developers or at DevOps. There are some fundamental differences between the two approaches that make this a big deal, and we will explain in this blog.
Part of the blurriness is due to the fact that these two approaches are not in two radically different directions. In fact, they are just two different points on the same continuum. To put it in simple terms, you could say that DevOps-First is version two and Dev-First is version one of the same high-level trend. Both are driven by similar and overlapping market forces, so there are many commonalities.
Before all this …
These trends are very recent, so before we start comparing these two trends, we should also talk about the earlier market approach . At Sken, we call that, the Security-First-AppSec era. This was when application security products were targeted and squarely sold squarely to the security team. This was radically different from the Dev-First and the DevOps-First approach. It made the most sense for that time. Primarily large enterprises were mass producing applications, so they cared the most about application security. These large enterprises had a number of in-house AppSec professionals and expertise, and so product vendors built products designed for and dependent on these AppSec teams. Their price tags were pretty expensive too.
Now, mid-market enterprises are mass producing applications as well and are equally interested in making sure that their applications are secure. This is the primary reason why the DevSecOps market is exploding. Unlike large enterprises, mid-markets typically do not have AppSec professionals or expertise, but what they do have, is developers and DevOps. So for the mid-markets, there is a clear need for a different approach. The other significant market transition in app development, has been the move from waterfall to an agile CI/CD approach. Agile calls for building and deploying apps much more frequently. With this model, the sooner the security issues are found in the SDLC, the better. This has created the “shift-left” movement, which places AppSec closer to developers and DevOps.
Read our other blog on DevOps first AppSec to understand why we are moving out of the security-first paradigm. So, if we agree that the mid-markets and agile development require a new approach – the next question that comes up is, which one is better – Dev-First or DevOps-First.
Developers Vs DevOps – Coding Vs Automation
As mentioned, the line between developers and DevOps can be blurry. In simple terms, the fundamental difference is that the developers are responsible for coding source code, whereas the DevOps are responsible for automating app deployment. Lack of clarity is typically the result of having the same person that wears both hats. While the developers have a mandate to write secure code, DevOps have the mandate to add security scanning to the automation. Both have some responsibility towards overall app security, but each is involved at different points of the workflow. To answer the question “Dev or DevOps first”, the key insight is that the workflow “begins” with DevOps, when they insert security scans into their CI/CD process. The CI/CD is almost exclusively owned by DevOps, and unless they take this critical action, it is impossible to run automated security scans. If scans are not executed, there is nothing that informs the developers about security issues in their code/app, so they have nothing (known) to fix, or do about security. Of course, the developer can run some scans manually, but the incentive to do it proactively is very low. Automated security scans in CI/CD also introduces a clear “gate” or phase where the developers are “required” to fix the prioritized security issues discovered by the automated scans to advance in the workflow.
Point of Integration – Source code repo Vs CI/CD
Now that we have established that AppSec requires automated security scanning, there are two places where it can be integrated effectively. One is the source code repository (which is owned by developers), the other is at the CI/CD (which is owned by DevOps).
Dev-First products target integration at the source code repository, whereas DevOps-First targets the CI/CD. Repos like GitHub have plugins for AppSec scans, that make automation at the source code repo easier. Most mid-markets use GitHub SaaS version, which also makes using the plugin a breeze. In the CI/CD world, the open-source software, Jenkins, is most often used and typically on generic cloud providers like AWS or Azure, but rarely in a hosted/SaaS manner (ex. Cloudbees). This makes the plugin management a wee bit more difficult.
Because of the relative ease of getting started, the Dev-First approach of integrating AppSec scans at the source code repo was a good first step in automation. As a result, over the last three years, Dev-First AppSec has been exploded in popularity with companies like Snyk, Sonarqube, etc. experiencing rocket ship like growth.
However, there is a big gap when running source code repo level scans. With the source code repo, you can only run scans that look at the static source code, known as SAST and SCA/OSS scans. Scans that can be executed after deployment, like DAST, API, etc. have dependency on the CI/CD, and can only be integrated there. To run the entire gamut of scans and to fully assess security, CI/CD is the only integration point. As an additional benefit, running all of the scans out of the CI/CD provides a single place to correlate output from different types of scans and to normalize them – which can significantly reduce noise.
Integrating at the source code repo was a good first step but as the market is transitioning and mid-marketing is burgeoning, the movement to integrating with the CI/CD is inevitable and with it, a movement from Dev-First to DevOps-First AppSec.
Complexity of scans
As a final point, because of the perceived complexity associated with deployment level scans, starting off with a Dev-First approach made sense. The deployment level scans can become complicated quickly, while source code level scans like SAST and SCA are perceived to be simple. Mid-market customers with limited AppSec knowledge may even have a false sense of security based on the assumption that doing only source code scans is “good enough”. The problem with that logic is that, security is only as good as the weakest link. Organizations leaving out deployment level scans, even if they did great work fixing the issues discovered in source code level scans, are still going to leave gaping security holes in their applications.
This is where Sken.ai comes in. Sken.ai is built DevOps-First from the ground up. Sken.ai makes running all types of scans, including deployment and the source code level scans equally easy. To achieve this, Sken.ai integrates at the right place – the CI/CD. DevOps, who owns CI/CD, do not need to have knowledge on AppSec – Sken takes care and abstracts out everything for them.
If you have had a taste of the efficiency that Dev-First scan brought in, you will love the next evolution in efficiency of DevOps-First scans through Sken. If you have not done any scans at all, not to worry, you can bypass Dev-First and catapult right into DevOps-First in one go by using Sken.