Blog Insights 5 Security testing principles every developer should know
September 16, 2019
5 min read

5 Security testing principles every developer should know

Developers are looking for guidance and standard practices as they take on more security testing responsibilities.


Principles of secure testing and how to do it

Security testing is no longer under sole ownership of the security team. New
tools have made it easy to bring testing into the DevOps model, where developers
can review and test code as they build out the app or software. However,
developers aren’t always on board with conducting security tests themselves:
Nearly half of security professionals surveyed in GitLab’s 2019 Global
Developer Report
(49%) said they
struggle to get developers to make remediation of vulnerabilities a priority.
Like the developers and operations professionals, 50% of security teams
surveyed also believe testing is what most slows down development. AppDev leaders can improve their teams' security practices by building team buy-in and adopting tools that make it easy for developers to follow the five principles outlined below.

Security should be with you every step of the way

We’ve reached a day and age where security can’t be an afterthought or bolt-on
activity: Everyone is responsible for ensuring their work does not put the
customer or business at risk. Security isn't just a box to check either, it’s a
way of operating that should stay with you through development, deployment, and
updates. Developers can adopt security as their own by following these five

1. Evangelize your security efforts

While developers are taking more responsibility for security, an overall
question of ownership still remains. Everyone should be responsible for
security, but all too often that “everyone” comes to mean “no one”. Dev team
leaders should advocate for security and the proper time to address it. Without
the proper advocacy, resources won't be allocated and security can become high-
risk technical debt. By shifting security left in the software development
process, developers can allocate resources early on while they are still
plentiful. Make it easy for your developers to adopt strong security practices
by creating team-wide guidelines, educating developers on best practices and
common challenges, and standardizing your expectations through both team and
individual security metrics.

2. Test early, test often

DevSecOps is an important next step in your DevOps initiatives. Security teams
are three times as likely to discover bugs before code is merged
, so test as you
code and begin fixing vulnerabilities as early as possible. By incorporating tools
that help with dependency scanning, dynamic application security testing (DAST),
and static application security testing (SAST), developers can get feedback as code is written and committed. These tools can give
developers information about the security of their code early in the development
process, making it faster and cheaper to remediate compared to making fixes later on.
In a mature DevOps model, teams are 90% more likely to test between
91% and 100% of all code than organizations with early-stage DevOps
Testing should continue throughout the DevOps lifecycle, so that developers are
able to change code before it’s integrated into the broader codebase. Frequent testing will
ultimately take less time and fewer resources, speed time to deployment, and
reduce friction between IT and security.

3. Always verify your changes with a second set of eyes

Writing and updating code should always be a joint effort. A second set of eyes
will spot potential issues that the author wasn’t able to see, and will reduce
the risk of deploying code that still has vulnerabilities. A randomized buddy
comes in handy here, to ensure that code reviews aren’t being handed to
the same person time after time, and allows different team members to
look at work that may be different from their own activities. Don't be afraid to
use tooling to help implement code reveiws and approvals. Configure your tooling
to require approvers within your merge request process.
Culture is an important element when it comes to code review: Your team of
developers must care about the integrity of the product or project as a whole,
and not just the speed or quality of their own code development.

4. Keep a master log of every code deployment, dependency, and update

Transparency is key to ensuring quality code. Creating a complete history of your code
will be helpful in reviews and incident response, and allows the security team or
developers to identify exactly when and where a vulnerability occurred. Teams should
also minimize any manual build or deployment processes to ensure that their
applications have full traceability and logging.
With a majority of application code being open source, dependencies have become a
major attack surface. What’s more, bugs in open source code generally fly under
the radar (no pun intended), undetected by developers until it’s too late.
Understanding, patching, and updating dependencies is critical, as catastrophic
breaches (such as WannaCry)
can and have occurred due to a missed update or patch. Security scans using updated vulnerability databases should be run on a regular
basis to maintain app security – even on code that has previously been scanned.

5. Diversify your security portfolio

Employ many different types of testing to cover your bases. A single type of
testing, like SAST, DAST, pre-release scanning, pen testing, or dependency
scanning is helpful, but won’t provide a complete view of your application
environment. Forrester's annual application security report
notes that security teams are adjusting their practices to help developers respond to
vulnerabilities at the speed of development. Some teams now conduct software
composition analysis ahead of production, and have moved static application
security testing (SAST) to early development (something your team can achieve
with GitLab
Others are using bug bounty programs to crowdsource vulnerability discovery,
which is particularly helpful for uncovering problems that don’t fall into known
security flaw patterns.

Work to achieve a DevSecOps model

Nearly 70% of developers are expected to write secure code, but only 25% of
developers believe they have “good” security practices. DevOps is a great place
to start: It’s clear from our data
that a more mature DevOps model encourages innovation and collaboration, and
enables teams to test more code faster. As more teams continue to shift their
security practices left, DevSecOps will become an advantageous reality for
developers and security professionals alike.

Cover photo by Patrick Tomasso
on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert