Counterintuitive, but does it make sense
“DevOps First AppSec” sounds very counterintuitive and even a bit insulting at its surface. The responsibility of application security falls on the eponymous application security team (or just the security team), so shouldn’t they be the first in line for its implementation as well? That is how it was, beginning with the inception of application security, but that is changing rapidly in many enterprises. DevOps are becoming the first point in the implementation cycle. This is not to mean that security has no role, or more importantly that the security team has become obsolete in AppSec. Quite the contrary, security professionals are in high demand and are expected to deliver even more sophisticated security in a world where security awareness and security requirements are on a continually increasing trend.
What this simply means is that DevOps has to be inserted first in the workflow of security implementation.
Why should I care?
- If you are a CISO of an enterprise or are otherwise responsible for security, you should make sure that there is a well-established system of cross-functional collaboration between DevOps and the Security team. This might have happened organically already, but if that is the case, it can undoubtedly use a better structure and control.
- If you are involved in building a security product, you should be acutely aware of this new user paradigm as it might affect the overall usability and go-to-market of your current security-first product in more ways than you think. It is easy to dismiss this trend as a nuance, but a fundamental shift in product and market thinking is required to accommodate this trend. The market will prefer products that better fit this new paradigm and will lead soon to lagging incumbents becoming obsolete.
Why is this happening?
It is a combination of a few trends; the rise of the agile CI/CD, the unique strengths of DevOps, a shortage of security experts, increasing security mandates in small and medium enterprises, and decentralization of application development top the list. Let’s look into each of these in a bit more detail.
Rise of the Agile CI/CD
Application development has moved from a waterfall to an agile mode. No longer does the security and the functional QA team have a clear, dedicated and month(s) long time window to test the security and the functionality of applications. Application changes are deployed on a weekly or nightly basis. This means the testing has to be done incrementally and in the same shorter time frame, and without slowing the process down. The result is a huge need to “automate” the workflow involved in building and deploying applications. CI/CD tools essentially provide this automation. The calls for security testing need to be automated and integrated into this CI/CD workflow. Without this, security testing is incomplete, and the organization leaves itself open to gapping risks. The solution for this could be trivialized to something as simple as using CI/CD plugins for the security scanning tools, and in some cases it is probably that simple, but in most cases this gets a lot more complicated.
- Many existing security scanners, commercial and open-source, aren’t built to handle the huge influx of security issues coming in daily and their so-called “vulnerability management” and “risk management” capabilities fall apart in this scenario.
- Application components and architecture also change more frequently, and teams have to continuously add, subtract, setup, re-setup relevant scanners to match this frequency This continuous setup and maintenance overhead add unnecessary demands on already stretched teams, and some scanners don’t even have a plugin for the CI/CD that you use.
- Since multiple scanners and types of scanners are now running at the same time and frequency (which in the waterfall world was much easily controlled and isolated), there is a need to aggregate and manage across scanners, which for most organizations, is a manual mishmash.
Automation of security scanners into the CI/CD is now a necessary first step in this entire process, but it can be complicated. DevOps “owns” 100% of the implementation and maintenance of CI/CD and suddenly they are in a much better position than the security teams to figure out this first step.
Unique strengths of the DevOps
As cloud adoption increases, DevOps teams are becoming more prominent in organizations, and automation is the key to DevOps. There are a multitude of DevOps tools focused on automating all the different workflows that DevOps are responsible for processing. Automation of security scanning tools in CI/CD starts with DevOps, too.
There are other unique attributes that make DevOps even more suited for this leading security role. Most DevOps come either from a system administration or a development background making them technical and hands-on. This puts in them in a natural position to quickly create sandboxes and test out the multiple tool choices available. If they are impressed with one, they are typically not shy to socialize and demo their findings, as selecting the elements of the CI/CD is a part of their daily job. Security teams are often not as hands-on as DevOps, and as a result, are more inclined to agree with DevOps.
DevOps influence in organizations is also increasing, putting them into a better position for their opinions to be heard relative to tool selection. Finally, there are simply more DevOps people than security people in most organizations, giving DevOps more bandwidth to test and evaluate solutions.
Shortage of security experts
CNBC reports that there are about 3M security positions open and unfilled. Enterprises, large and small are feeling the effects of it. Security teams are having major problems scaling to cater to the ever-increasing number of applications in an enterprise. Security teams have wide responsibilities beyond AppSec and do not have the bandwidth for everything, thus they become a bottleneck in many decisions or procurement processes. With this shortage of security personnel, DevOps often have more bandwidth, as well as the inclination to take the initial step of automating security scanning in CI/CD.
The other aspect of this security shortage is that there is going to be a preference for tools that do not require a lot of security expertise to use. Security-first incumbent products often require strong security expertise to use them. A DevOps first approach, by definition, needs to be built to provide a strong user experience, even for non-security users.
Increasing security mandates in small and medium enterprises
Market research shows that the DevSecOps market is expected to explode primarily because of the increase in adoption of security practices by small and medium enterprises (SME). SMEs do not usually have experts in security, but they increasingly have DevOps. This makes it easier for them to adopt DevOps First AppSec products, which do not need significant security expertise, and are “easy to use”. Most security-first AppSec products are complicated for a security novice as they require a lot of security expertise.
SMEs also like enterprise tools that they can adopt at a grassroots level. This trend is also referred to as the consumerization of enterprise tech. Products like Dropbox, Slack, etc. are good examples. DevOps first AppSec products fit this model very well, while most security first AppSec can only follow a traditional top-down sales model. As explained before, DevOps has the technical and hands-on capability to quickly try out new products in a sandbox, and then socialize and bring adoption from the ground up, rather than waiting for a top-down sale process to happen.
The third factor for SMEs is affordability. Commercial security first products are expensive. Grassroots model products typically are more affordable, and even free for some use, than top-down sales model products. The cost difference often is by a large factor. This way DevOps First AppSec products can bring more affordable application security options to SMEs
Decentralization of application development
On the other side, in large enterprises, there is also a trend towards decentralization of the application development process. These decentralized teams mimic the attributes of SMEs mentioned above, and similarly, prefer easy, affordable, grassroots products. Products like Dropbox, Slack, etc. made their way from SMEs into large organizations because of this decentralization. DevOps First AppSec products can follow the same trajectory.
Meet Sken.ai
Sken.ai was built from the ground up in a DevOps first AppSec model.
Sken provides a SaaS orchestration layer that integrates continuous application security testing into your DevOps CI/CD workflow, using open source security scanners, across all scan types (SAST, DAST, SCA and more). For DevOps, Sken offers a single CI/CD automation layer for all scan types and scanners. This eliminates the need to plug-in multiple siloed scanners into the CI/CD.
DevOps can get started with Sken in just two easy steps, and it takes less than a minute.
Sken provides an easy, affordable and grassroots product for SMEs and decentralized teams in large enterprises. Sken uses a combination of free open source security scanners which also makes AppSec more affordable for these organizations. Sken does this across all scan types to offer an end-to-end solution. It automatically selects the relevant scanners and manages their setup, configuration, and lifecycle. Sken aggregates findings across scanners. Its web portal provides vulnerability and risk management functionalities. It is so easy that DevOps needs very minimal security knowledge to adopt it.
Finally, the best news is that Sken’s business model offers free scanning for most SMEs, so DevOps can adopt it in a truly grassroots manner.
