Beyond the financial risk of high regulatory non-compliance fines as a result of falling victim to a data breach, every company has a duty to protect the sensitive data of their customers and employees. If they fail to do so, they not only violate the law but, crucially, they put their reputation at stake by compromising trust.

The most effective way to detect security vulnerabilities is to test software for potential weaknesses and remedy them before a product goes to market. However, up until recently, security testing has been deprioritised by software delivery teams. This can be attributed to factors such as time pressure and a central focus on delivering innovative and user-friendly products to stay ahead of the competition.

Yet times are changing. Over the last few years within the DevOps community, there has been a gradual shift in mindset around security. Since its inception, a core element of DevOps has been to deliver value to the customer rapidly. But when met with tight deadlines, potential security weaknesses can be introduced or overlooked. This is why DevOps teams have started to take more accountability for establishing security testing within the continuous testing process.

Security testing in DevOps

The concept of fostering a sense of shared responsibility around security, and essentially embedding it within the process of software delivery, is commonly known as ‘DevSecOps’. Ultimately, everyone on a DevOps team, from the developers to the testers and the operations staff, is obligated to pay attention to ensuring their software is secure. This applies to every stage of the process – including design, development and production.

Firstly, DevOps teams are required to think about potential security vulnerabilities that could be introduced or exposed in the initial software design. By including security criteria for each user story, the team can then test the designs as part of their automated continuous testing cycles.

Importantly, as the software along with its components and configuration move along the implementation pipeline, these security tests are always running. This means that if weaknesses are spotted at any stage, the team will be notified. With this alert, they can find a solution to issues as and when they arise.

What’s more, when the software is deployed, additional security tests are run to ensure that when it’s in production, the software is scanned for vulnerabilities stemming from configuration changes, software updates, and environment changes.

Embedding security

 In practical terms, here are three key steps that teams can take to integrate security into DevOps.

1- Security training for testers and developers

 The majority of organisations find that they don’t have enough security talent to fill DevOps roles. It’s vital that developers and testers are provided with security training to help them understand how they can incorporate security into the design, coding, code reviews and testing of a product. One way to ensure that security is continually part of the DevOps conversation is to encourage a couple of members of the team to take on the role as ‘security champion’.

In addition, teams should be given constant threat modelling sessions. This consists of taking a proactive approach to identifying weaknesses in the application design – in other words, thinking like a hacker. Threat modelling can do a lot to reveal architectural weaknesses that, if exploited, could lead to malicious actors accessing sensitive data.

2-Applying automated security testing tools

 Automated security testing tools run quicker than manual tests, making them ideal for continuous testing. There are two types of automated security testing tools that are typically employed: Static Application Security Testing (SAST) tools and Dynamic Application Security Testing (DAST) tools. SAST is used to spot weaknesses in source code, while DAST scans for weaknesses while the code executes in a testing environment.

Teams need to be aware that SAST and DAST can take a long time to run on a large application. They can also produce a high number of false positives which can act as red herrings when it comes to finding more serious issues. To maximise the potential of these tools for continuous testing and to save time, teams are required to hone in on the areas of code that have recently changed and configure the tools correctly.

3-Protecting the production environment

The production environment is where real-life users interact with the system. This is where unnoticed weaknesses surface, leaving access points exposed to potential hackers. It’s imperative that continuous security tests are run on the production system as updates are implemented.

At the same time, constantly running security tests has the potential to slow systems down significantly – or even bring them to a standstill altogether. With that in mind, teams need to plan for possible disruption. Moreover, by utilising a Runtime Application Security Protection (RASP) solution, unlawful intrusions can be pinpointed and prevented in real-time.

DevOps and DevSecOps – is there a difference?

The security aspects of software are increasingly core to its functionality. This fact, alongside the growing uptake of automated testing tools, means that teams should question whether DevOps and DevSecOps still represent two distinct options.

Ultimately, regardless of the terminology, security needs to be a main part of software delivery – or else businesses and their customers should be prepared to face the consequences.

By Malcolm Isaacs, head of ADM solutions marketing at Micro Focus