1. Autonomous security from day one
Automation in security is critical.
By making repeatable processes, it
reduces the number of human steps
slowing things down. But the most
important reason why security needs
to be automated is because that’s how
the development teams are working.
By automating security, companies
don’t need a separate security team to
implement work with the development
team. This is part of the developers’
process and is becoming the standard
way of building software.
In order to do this, the first step in
automating security is to look at what
tools you already have in place, then
figure out the best points to automate
in some of the security testing you want
to do.
The next step after making sure the
tests are running autonomously is to
make sure the results are captured in an
automated way so this feedback can be
integrated into defect tracking systems
to further improve the process.
2. Integrate as you code
When working with organisations
that want to integrate security into
the continuous delivery process, the
overriding principle is to put this process in
www.intelligentcio.com
“
WITH THE RISE
OF DEVSECOPS,
FINDING AND
FIXING SECURITY-
RELATED DEFECTS
IS A SHARED
RESPONSIBILITY
BETWEEN
SECURITY AND
DEVELOPMENT
TEAMS.
place as early in the development lifecycle
as possible. This is essential to create a
tight feedback loop between discovery
of a problem and allowing a developer
to fix the issue quickly. It’s much faster
and cheaper to ask a developer to fix
something they’ve just coded rather than
six months down the line.
Performing security testing just as the
developer is writing the code allows
for instant feedback. We want to
enable developers to be able to do
application security testing, but most
don’t have an understanding of fixing
flaws in the same way application
security professionals do. To add to
this, developers are following strict
timelines for delivering code. Ideally,
application security should be viewed
as an ongoing partnership between
development and security, where
security defines what’s acceptable
from a quality level, and the developers
implement the testing and address
issues as they come up.
3. Avoid false alarms
Like any form of testing, application
security testing can suffer from false
alarms – where the test returns a
result indicating a problem when one
doesn’t exist. It’s common for earlier
generations of application security
tools to return false alarms because
they were designed to show all the
possible issues in a piece of software,
including false positives. The problem
with this approach is its very difficult
to integrate these tools into a shift left
workflow because the results have to
be reviewed before the developer can
process them.
INTELLIGENTCIO
47