Three rules for turning DevOps into DevSecOps
Content Marketing at Probely
Why DevSecOps?
There’s a general idea that the faster our development and deployment methods get, the more prone they might be to security issues. And as we get to a point where development is agile, fast, and functional, we start questioning ourselves: Is this all secure? And more importantly, what will it take to improve the security of our projects?
As DevOps practices matured in the industry, security was left in the periphery, and only now are we starting to see improvements. With agile development and fast code deployments, we also saw a wave of fast vulnerability introductions to the apps. And since most DevOps stacks prioritize functionality and speed over security, practitioners are often discouraged to go through security checks since it slows down the process. However, eye opening breaches like the British Airways breach of 2018, proved how important it is to improve our DevOps practices and integrate as many security checks as possible. Especially after seeing the legal consequences and the GDPR fines that British Airways recently faced (around $230 million).
DevOps “vs.” DevSecOps
The merger of development and operations is quite a natural one. Dev teams and Ops teams have always had the same aim in mind: to release functional apps to customers as quickly as possible. However, security appears to be a hindrance in the process. Development and operations aim at fast and functional release. On the other hand, security, with all the audits and time consuming tests, seems to be slowing releases down, thus hindering the DevOps process. Knowing this, it’s not a surprise that many developers deem security to be an obstacle rather than a necessary and complementary part of the Software Development Life Cycle (SDLC). That’s where this “DevOps vs. DevSecOps” dialectic stems from. However, lately we’ve seen many security practitioners begin to understand that if security doesn’t shift left in the SDLC, it will be left out in the DevOps era. The earlier security enters the SDLC, the less of a hindrance it will be to agile developers. Even though incorporating security in DevOps might slow down the development process a bit, it will generally decrease time-to-market and improve the well being of your company.
So, are DevOps and DevSecOps on opposing sides?
Even though they appear to be, the two don’t contradict. We know that security must be taken care of somehow, and what’s a better way to do it other than nurturing the synergy between development, operations, and security early on. Making security a crucial part of your workflow isn’t necessarily a shift away from DevOps, but an advancement of the old system.
Well, how do you successfully turn DevOps into DevSecOps?
Here are some rules or best practices to help you get there:
Rule #1: Start easy and automate
When trying to incorporate security into DevOps practices, we come across two issues: speed and a lack of awareness regarding security. That’s why when you first start with turning DevOps into DevSecOps you have to make sure that the process is fast and smooth for the developers. You want to, ‘ease in’ security to your development life cycle. To do that, it’s important to avoid frustrating developers with nuisances like false positives, security tools that are hard to understand, and long code reviews. At the same time, you want to automate security as left as possible in your workflow so security issues can be found early on. To top it all off, since it’s the developers that will be fixing the vulnerabilities, you’ll want to make sure that they know how to fix them properly or that they have correct and relevant guidance.
So, what’s your first step here?
You have to make sure that deploying secure applications is easy for the developers and that it can be done fast. To do that, you will need a tool that is understandable and feels intuitive to developers, and at the same time automates your security testing process.
That’s where Application Security Testing (AST) tools come into play. There are two major types of ASTs (there are more than two, but these are the most common ones): D(dynamic)AST and S(static)AST. The difference between the two is that SAST tools scan the code for vulnerabilities, and DAST tools scan the application once it’s functional. Since DAST tools try to attack the application and find security issues like a hacker would, they report a lot more relevant findings with substantial evidence regarding the vulnerability. A SAST scanner might seem like the right choice here because they scan the code earlier in the workflow. However, the fact is that SAST scanners report a lot more false positives and irrelevant findings might turn developers down. On the other hand, DAST results are easier for developers to understand, and since they show the consequences of a vulnerability, the developer gets an idea of how severe the risk is. Most good DAST scanners will also have plugins and powerful APIs that will let you integrate them with popular CI tools, like CircleCI. Some of them, like Probely, will provide your developers with tailored guidance on how to fix the issues found.
DAST scanners are a good first step in turning DevOps into DevSecOps. They make it less frustrating for developers to deal with vulnerability scanning and easier for them to understand the security risk. And DAST scanners can be seamlessly integrated into your CI/CD pipeline.
Rule #2: Prioritize
Speed is key when it comes to DevSecOps and prioritization is key for speed. When it comes to integrating security into your established DevOps practices, automation and speed shouldn’t suffer. To achieve that, you have to prioritize. You have to map each application, and each vulnerability, to a risk. For example, you want to pay more attention to the security of an app that deals with sensitive customer information. Further, you will want to take the context of each vulnerability and map it to the potential risk it holds for your business or company. When you do that, prioritize the vulnerabilities with a high risk scoring. Probely, as a DAST scanner, automatically does part of the job for you. It ranks vulnerabilities, given the context, into three categories: High, Medium, and Low.
Prioritization helps you focus on what matters and keeps you from loading too much work onto your developers. This will help you with the Dev-Sec synergy.
Rule #3: Demonstrate and educate
When integrating security into your company, it’s not sufficient to just incorporate DevSecOps practices, set up rules, and ask people to follow them. DevSecOps is a lot more about company culture rather than a set of procedural practices. It’s a way of organizing and thinking. You can start by educating your developers and other employees about security. You can start by providing them with this web application security checklist. Often, developers and staff in your company won’t understand the importance of security and will underestimate a lot of the risks. To educate them properly, you will want to demonstrate the process and the risks.
Educating you developers on secure coding and awareness is not enough. The culture of your company should embrace security as a whole. Other than demonstrating the evidence of vulnerabilities and exploits provided by your DAST tool to your technical staff, you should also do company-wide demonstrations. Fake, but well crafted, phishing and social engineering attacks that target both technical and non-technical staff bring a lot of visibility and engagement. Thus, education and raising awareness about this is crucial. You can start by demonstrating the implications of a phishing attack by doing a “mock” phishing attack yourself. Send out a malicious email and see how many employees in your company click on the link and give off any classified data. This will help you both present the risk of attacks like this and educate non-technical staff.
Bonus Rule: Rules are meant to be broken
The beauty of DevOps and DevSecOps is that you can bend the existing rules or make your own. So, if some of these rules aren’t compatible within your company, don’t worry, there’s always a way around that. Feel free to adapt DevSecOps practices to your own case. Play around with different tools, see if you can afford pentesting or bug bounties, invest time and money in network security, etc. There’s no ‘right way’ of doing things with a standardized set of security rules.
What DAST tool should I use?
There are many good DAST tools and vulnerability scanners out there, but which one should you use? The answer depends on your personal preferences, budget, and company size, but generally, you will want a DAST tool that is fast, easily integrates with CI tools and other applications, has a powerful API, and provides your developers with an intuitive UI and with relevant information about the vulnerabilities that it found (how to fix, evidence, description). If you are using CircleCI, you will want to have a DAST tool that has a matching orb. This way you will be able to easily integrate security into your CircleCI workflow.
For this, you can use Probely’s orb. Probely allows you to scan your web application for over 1000 of vulnerabilities, and it has all the features named above. Developers appreciate Probely because it’s intuitive and shows relevant information. Besides showing evidence that the vulnerability is real, Probely detects the language or the technology used to build the app, and based on that, provides users with tailored instructions on how to fix the vulnerabilities.
This post is a part of a series we produced covering DevSecOps. To read more posts from this series, click one of the links below.
