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.