Taking on Security Automation

Increasing risk exposure in modern software

• By Felicia Haggarty
• Dec 01, 2019

Security experts are sounding the alarm about risks in the software development process. Not only does modern software architecture create a broader attack surface area, the accelerated DevOps methodology makes it harder to detect and remediate vulnerabilities. The heart of this issue is that DevOps teams are challenged to take on new security responsibilities. This is not a role they are trained to play, but it is possible to make developers an extension of your security strategy. New tools for automated security in DevOps remove much of the security burden placed on developers—but do so in ways that make them part of the solution at the same time, while not slowing development.

DevOps as a Driver of Increasing Risk Exposure in Modern Software

DevOps teams offer much to businesses who employ it. Assuming you can pull off the tricky integration between two different and organizationally-distinct groups, the result is faster software development cycles and alignment with agile methodologies. Combined with practices such as Continuous Integration and Continuous Deployment (CI/CD), DevOps enables the release of new software features at a rapid clip.

This is great until you start to look at DevOps from the perspective of information security. The pace of development is simply too fast for traditional application security techniques to work. According to SANS Institute research, 43 percent of organizations are pushing out changes to their software either daily, weekly or continuously. Historically, software testing was intended to reveal security flaws in a new application. There is little time built for manual AppSec inspection into these processes on today’s rapid DevOps timetable.

The nature of software vulnerability is also evolving, making code developed using DevOps that much more vulnerable. Undetected at the source, hackers can plant malware into the vast open source code libraries that DevOps teams draw on for their work. This is an astonishing 79 percent of code. Now, those libraries can carry malicious code.

The Fallacy of Expecting Developers to Enforce Security Policies

Development professionals already have a full-time job: writing great code. Their skill sets revolve around code. They get paid to write code and fix bugs. Bonuses are based on writing code to deliver new products and features that popularize applications. They are used to having an arm’s-length relationship with security. Developers care about security if, and when, it helps to make their products better, faster and more reliable. However, if a vulnerability seems theoretical, or worse the issue is a security “code hygiene” practice, then developers may not give that type of security escalation much priority.

A new approach today involves continuous follow up with dynamic, run-time analysis that can uncover real security problems. Done right, automated analysis identifies critical issues with a clear path to remediation. Once a problem is uncovered, the developer can address it as a software “bug,” e.g. JIRA ticket that includes secure code samples and recommendations to make the remediation straightforward.

The need for automated security discovery without the burden of being trained as a security professional is crucial. It is possible to make DevOps more secure. Armed with this automation, developers will be able to test for vulnerabilities sooner in the development process instead of at the end or after there is a huge breach and they have to rebuild, rewrite code or find a new job anyway.

This article originally appeared in the November/December 2019 issue of Security Today.