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.

security-testing-principles-devs.jpg

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 principles:

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 system 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