After uniting development and operations to ship more code faster, Gartner believe that DevOps teams are set to handle security as another major obstacle to overcome. Contrary to DevOps processes, many current security controls are either not completed, or are managed as gates that DevOps teams must go through instead of integrating processes together.
The prediction by Gartner analysts is that the number of teams adding security into DevOps practices will increase from 40% today to about 90% by 2022. There are multiple benefits for teams that integrate security into their DevOps processes. By understanding threats that an application faces, teams can defend against the right risk at the right place to decrease the probabilities of data breaches, data loss, and other various exposures.
Although security experts can still monitor various aspects of software, a crucial tenet of DevOps is the ability to operate at scale and speed, free of arbitrary organizational and technical bottlenecks. The beneficial security tools will fit in line with other components of the DevOps toolchain to provide continuous feedback at all times: as code is written, across the CI/CD pipeline, and to monitor and understand threats against the code as it runs in test and production environments.
Teams looking to understand how to improve security can leverage educational material that is available online. Various free training courses are available to explain the role of security in DevOps: training for managers, and training for technical practitioners. "Training and security education is another crucial piece of the puzzle," states Calvin Lo, program manager for training SecurityCompass. He continued:
By understanding threats and weaknesses of how applications are hacked, software professionals can gain direct expertise and then prevent many common problems from happening in the first place.
One tool on Gartner’s roadmap is IAST, or "Interactive Application Security Testing". IAST helps teams understand and address security during development and testing, in a manner similar to how Application Performance Management (APM) tools helped teams understand performance. Instead of sending code to a specialized performance team to evaluate isolated tests in a lab, APM tools such as New Relic, Dynatrace, and AppDynamics used instrumentation to continuously monitor what happened in an application without requiring code changes. As a result, teams could monitor their own data without requiring dedicated study in the field of performance engineering.
With tools such as IAST, teams can leverage tools to find security defects without requiring dedicated study in security risk. As a result, these newer DevOps tools can locate security defects by identifying interesting occurrences, such as: when user input reaches an SQL command without validation (SQL Injection), where an XML parser is configured to provide local files to external users (XXE), and many other types of risk. By monitoring code within APIs, IAST analyzers can also assist with mapping an application’s flow to other resources, and accordingly act as the basis for an automated threat model.
"DevOps has dramatically improved the way that teams ship software quality and performance. DevSecOps has similar benefits for security, but requires changes in culture, people, process, and technology. Successful teams are both shifting security 'left' into development as well as extending 'right' into operations, and they’re leveraging instrumentation-based approaches like IAST and RASP instead of traditional outside-in scanners and firewalls."
Jeff Williams, CTO of Contrast Security, which provides a free IAST monitor in Contrast Community Edition.
Other notable tools in the security DevOps pipeline are:
- Software composition analysis: a way of identifying vulnerabilities and/or potential license conflicts within an application’s libraries.
- Chaos engineering: the introduction of periodic errors and/or environmental degradation in and around an application to help manage its resilience before a similar unexpected error occurs.
- Runtime application self-protection: a way to make running applications defend themselves by applying the context of what the code is doing. Unlike external defenses that watch network traffic, this technique identifies when and how data is used.
The core issues of many security tool chains are speed, skillset, and accuracy. Some tools, such as security static code analysis, are too slow and provide too many false positives through the inability to traverse non-imperative code flows (such as inversion of control). Triaging the false positives requires an expert who is typically not present in most software teams.
Others tools, such as Web Application Firewalls (WAFs), suffer from accuracy of understanding what they see. Although WAFs can monitor a production environment to see data moving across a network, they lack an architectural visibility to differentiate if and when an attack matters. The result is that operations teams receive significant noise from irrelevant crawler attacks, and developers cannot utilize attack information to improve in a meaningful way. For example SQL Injection blocking statistics do not matter to a team whose application uses NoSQL.
In 2014, the security industry published statistics that organizations in the United States were attacked over 5,000 times per hour. Other data from 2018 indicate that organizations are attacked 1,000 times per day. The key aspect missing from these network-based WAF reports in a DevOps pipeline is how often these attacks can actually accomplish something that the defender cares about.
Developers looking to improve security while maintaining a rapid release cycle can evaluate the Gartner cycle, or look to the Microsoft SDL for other recommendations. There are also other tools to consider, such as Contrast Community Edition and OWASP Dependency Check.