DevSecOps – a buzzword or a new necessity?

If done right, DevOps implementation should bring fruitful results to any organization: better collaboration between teams, faster time to market, improved overall productivity, and enhanced customer satisfaction, to name a few. But let’s think what happens if you don’t make application security your number 1 priority?

DevOps Security

Vulnerabilities pose a serious threat to software, but not only financial and reputational. Big amount of confidential information can be also leaked – from internal documents to unreleased products and personal customer data (including passwords). Depending on the jurisdiction, breaches of user data can result in severe financial penalties and legal liability.

Despite all this, development teams often see security not as a possible asset, but as a burden. Security audits and reporting slow things down and prevent new features from being delivered right into the hands of users. This thinking can play into the hands of attackers.

Also the code is written by people, and people may mistakes. To say nothing of different 3rd party integrations where you can’t be 100% certain that they are free from vulnerabilities.

So how do you include security aspects in the software development cycle? The DevSecOps approach proposes to apply to security practices the same principles that allow us to establish fast stable releases – the principles of cooperation, shared responsibility, and maximum automation.

Security shift to the left

Waterfall development involves a linear approach: first, requirements gathering, then design, development, integration, testing, and finally (months or even years later) release.

The testing phase typically included lengthy manual processes of quality control, security auditing, and acceptance testing. The process is ironically referred to as “throwing software over the wall”: the product was simply passed from one team to another, and each made its own long report.

The information security team was usually responsible for one of these stages. It was compiling a security report with a detailed list of issues found and recommendations. Often, changes in the code were required, after which it was necessary to repeat all the stages to make sure that everything was implemented correctly (or incorrectly). It is not surprising that with such a protracted process, the releases became a real celebration.

Agile development methodologies, the DevOps movement and the development of cloud computing have changed the situation. In a highly competitive environment, speed is critical. If you don’t address user needs and resolve issues quickly, users will soon choose another provider instead of you. Therefore, regular releases and the ability to quickly release bug fixes have become the new standard for many organizations, and the CI/CD pipeline is a key part of their processes.

The appearance of the term DevSecOps does not mean that DevOps excludes security issues. However, unfortunately, in reality it turned out that with the unification of the development and operations teams the information security teams were mostly left on the sidelines. To solve this problem, they came up with DevSecOps, as well as several variations of it, such as SecDevOps, DevOpsSec and Rugged DevOps.

DevSecOps emphasizes the importance of building security from the start, incorporating security into a culture of shared understanding and accountability, and building security checks into automated CI/CD pipeline tests. As with operations, instead of implementing security requirements and practices after the product is built, it is better to shift security to the left.

Adding Sec to DevSecOps: Security as Code

Here you might think that the security shift to the left means that you just have to submit your software for testing by the security team as part of the CI/CD pipeline. Manual security testing certainly has a place in the process, and we will discuss this in more detail below. However, by relegating security requirements to just a step at the end of the pipeline, you are essentially doing the same “throw software over the wall” and waiting for the report to arrive.

As a result, most likely, the recommendations will be ignored, because the implementation will take a long time, or the whole process will stop with a roar and the release will be postponed indefinitely – to solve the problems found and assess the risks. One way or another, this creates a disconnect between the security team and everyone else, which makes it difficult to achieve the desired result – the release of valuable yet secure software.

How does the shift left method work in practice? There is no one-size-fits-all solution, but there is a set of tools and techniques that help integrate security issues into the software development cycle.

• Appoint Security Experts

Shared responsibility is important, however don’t just tell the developers that now it’s their concern now, but rather of a separate employee keeping track of new attack vectors and malware developments. By adding a security expert to your multidisciplinary team who shares his knowledge of best practices, you will help your employees recognize and maintain a culture of collaboration with security professionals.

• Consider safety at the design stage

Security should be reflected in user stories. It should be discussed when reviewing the backlog and planning sprints. As you think about new functionality, take the time to consider the risks it might pose and how you can mitigate it.

The STRIDE threat modeling strategy and tools like the OWASP cheat sheet will help you stay on track. Thinking about security at the design stage won’t take everything into account, but it will get you off to a good start and promote a DevSecOps culture.

• Add automated security tests to the pipeline

Automation is a central tenet of DevOps. It not only speeds up tasks and ensures consistency, but also offloads people, freeing up time for more creative work. If you want to deliver a product to users regularly and frequently, it is important that you have automated security tests in your pipeline.

When writing unit tests, as well as automated integration and end-to-end tests, security should be considered on par with any other functionality. If your team incorporated security requirements into user stories and threat models during the design phase, it’s only natural to add tests that cover these features.

• Get the help of experts

There are various testing tools on the market that will help you be more confident in the quality of your code apart from the testing that you do. Traditional security scanning tools are not well suited to automated CI/CD pipelines. But there are tools specifically designed for automation and integrating into pipelines. They publish the results to a dashboard or submit them directly to bug trackers. As with any automated test, it makes sense to introduce a structure in order to quickly get results for different categories.

Static Application Security Testing (SAST) tools perform static code analysis, testing it for known vulnerabilities (buffer overflows, SQL injection, etc.). Because static code analysis is performed on source code, it can be run early in the CI/CD pipeline, right after changes are committed.

SAST tools are language bound. Some of them integrate with the IDE, thus providing a continuous feedback loop (right in the course of writing code) and the ability to run tests at any time. SAST tools point developers to lines of code that contain vulnerabilities, allowing them to quickly make fixes. However, there are also false positives. To prevent SAST results from becoming useless background noise, it’s important to be able to turn off some notifications.

Following SAST, Dynamic Application Security Testing (DAST) also appeared. They treat the application as a black box and check it for known vulnerabilities such as cross-site scripting, command and SQL injection, and insecure server configuration. DAST tools work with an already built and deployed application, so they are typically used in the later stages of the CI/CD pipeline.

• Check Dependencies

Software Composition/Component Analysis (SCA) is another type of automated security testing that can be done early in the process. As mentioned above, almost any codebase includes libraries and other open source components that can introduce vulnerabilities.

SCA tools examine not only the dependencies present, but the dependencies of each dependency (recursively). This is a great example of a task that is more efficient to perform on a computer, especially considering how often dependencies are added to the project.

SCA tools can be automatically run within CI/CD pipelines. Some of them are also available as IDE plugins that provide on-the-fly feedback. SCA testing (just like static and dynamic testing) analyzes software only for known vulnerabilities. Therefore, you need to ensure that the tools you use are regularly updated with new vulnerabilities and cover those areas that are relevant to your product and organization. When it comes to finding new vulnerabilities (which you don’t expect), you can’t do without human intervention.

• Сall the red team

The concept of the red team comes from war games, where you ask your teammates to simulate an enemy attack in order to determine the weak points of your defense and strategy. The same approach is widely used in software development, for example in the form of penetration testing or ethical hacking.

For the red team to work effectively, they must not be involved in the development of the system under test. Like those involved in exploratory testing, red team testers need to be able to think outside the box and use software inappropriately.

The red team can work either in a test environment (as close to production as possible) or directly with the system in production. The latter assumes that you can confidently rely on the behavior of your system in the event of an error, or you have very tolerant users (and highly professional managers!).

• Vulnerabilities are the same errors

The DevSecOps approach assumes that the entire team is responsible for product security. Therefore, it is not necessary to separate vulnerabilities and “normal” errors. Any vulnerabilities you discover should be in the same backlog as other issues and prioritized on par with them.

Responsibility for fixing vulnerabilities lies with the entire team, not just the security expert. This approach helps to expand the knowledge and expertise of the team, and the acquired skills can later be applied to other projects.

• Follow the production

Despite all the measures that you have taken in the previous stages of the development cycle, the risk that a hacker will still find a weak spot in your system still remains. To protect your organization and users, it makes sense to include firewalls and monitoring tools. Runtime Application Self Protection (RASP) tools also provide additional protection by automatically detecting and blocking suspicious behavior