DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » DevSecOps » Security Testing: Reducing Resistance to Change in an Agile and DevOps World

Security Testing Reducing Resistance Agile DevOps

Security Testing: Reducing Resistance to Change in an Agile and DevOps World

By: Andrew van der Stock on February 20, 2019 1 Comment

Software development has evolved, but security testing has not. That has to change

Related Posts
  • Security Testing: Reducing Resistance to Change in an Agile and DevOps World
  • DevSecOps Deluge: Choosing the Right Tools
  • What is DevSecOps?
    Related Categories
  • Blogs
  • DevSecOps
    Related Topics
  • application security
  • devsecops
  • integration security
  • security audits
  • security testing
Show more
Show less

In the bad, old days—which, sadly, many are still living in—security testing was tacked onto the end of the development process. Security testing hasn’t been a feature of software engineering for around 15 years now, since agile supplanted waterfall as the primary development methodology. The old idea of security testing as an independent, external audit, where security folks sit far outside the development process, is ineffective at preventing massive data breaches and ensuring developers have the knowledge required to build secure applications.

DevOps Connect:DevSecOps @ RSAC 2022

Until the mid-1970s, the concept of desk-checking software was necessary due to the slow turnaround time of punch cards, compilation and batch job testing. Desk-checking and formal verification are the genesis of the security audit. Though software engineering has developed through timesharing, real-time debugging, individual computers for each developer, waterfall, object-oriented programming, rapid application development and, finally, agile and DevOps, security is still stuck in the mid-1970s. Security professionals are not auditors and security audits are not a viable replacement for sound security engineering.

There is no doubting the need for objective tests along the way, but the construction industry shows us the way here. Any large building project regularly tests random concrete deliveries for compression and tensile strength. While every metaphor breaks down if you push it too far, there is a place for continuous security testing in an agile world. This should take the form of executable tests, rather than reports.

Modern “unicorn” development is proud of the DevOps culture that allows developers to push code into production many times a day. But in the DevOps deployment model, it’s impossible for traditional security practices to keep up. A typical security testing schedule is every 12 to 18 months if you’re lucky, or never if the app is not considered significant. There could be thousands of untested builds in that time.

How do we fix this? How do we scale? The security profession must adopt agile and DevOps processes and use the same tools as developers. It is that simple. However, it’s incredibly difficult for many. Historically, security professionals haven’t come from a development background, and so the concept of delivering security tests as source code is at odds with 40 years of penetration testing.

The first thing that must change is the way organizations receive results. One of the tenets of an early agile methodology called “extreme programming” (XP) is “you ain’t gonna need it” (YAGNI). I posit you “ain’t gonna need” a PDF report. Results should be delivered via APIs, directly into existing development defect trackers, such as Jira or GitHub Issues, or a vulnerability management solution. The worst possible outcome is a 60-page PDF sitting unread in someone’s inbox—or worse, trying to scrape it or manually cut and paste into an Excel spreadsheet. Developers will never see the entire report, as if it is a state secret, and yet they have to fix discovered issues.

I hear screams in the distance! How’s an internal audit going to verify that security is in place and effective without a PDF report? They can and should look at the results of builds. It is that simple. If developers can demonstrate that every build for the last 12 months passed security unit and security tests, that is a job well-done. No one asks accountants to provide a PDF report of the latest reconciliation as proof that reconciliation is working. The evidence is that the numbers are the same in the online accounting and banking systems. If an auditor wants to produce a cover sheet saying that they randomly sampled build testing results over the last 12 months and assert that the results are a true and correct representation of security effectiveness, good for them.

Security professionals are not auditors and should not be writing reports. They should be testing software, sharing knowledge and writing tests. Security professionals should be embedded with developers, helping them understand why a security test has failed and discussing solutions, possibly even coding a potential solution. Security professionals can learn about the enterprise and specific application business risks, and the development team can learn how to fix current issues and protect against security failures in the future.

It’s critical to understand that as executives ponder this change, there will be resistance. The security industry is structured around delivering short-duration, high-skill testing. This type of testing often tests the skill of the assessor and web application firewalls, and not the application itself. Modern security practices—such as the one I lead—have moved to abuse cases, where no web application firewall will protect you. We have offerings and talk with our clients about agile CI/CD pipeline security, but even though what we want to move on to will be utterly obvious to everyone in a year or two, resistance is strong.

How do you move forward in the interim? Ask your security vendors to deliver proof-of-concept unit or integration security test cases to be run in the build pipeline. Provide source code to your apps so they can write the tests in the same codebase to test every build and allow your developers to maintain these tests.

In the meantime, review the effectiveness of your PDF-based security program. Challenge your vendors to come up with something that works with your development teams rather than treating them as adversaries.

— Andrew van der Stock

Filed Under: Blogs, DevSecOps Tagged With: application security, devsecops, integration security, security audits, security testing

Sponsored Content
Featured eBook
The 101 of Continuous Software Delivery

The 101 of Continuous Software Delivery

Now, more than ever, companies who rapidly react to changing market conditions and customer behavior will have a competitive edge.  Innovation-driven response is successful not only when a company has new ideas, but also when the software needed to implement them is delivered quickly. Companies who have weathered recent events ... Read More
« Production Work in the Real World
Will ITIL V4 Bring Order to a DevOps World? »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Continuous Deployment
Monday, July 11, 2022 - 1:00 pm EDT
Using External Tables to Store and Query Data on MinIO With SQL Server 2022
Tuesday, July 12, 2022 - 11:00 am EDT
Goldilocks and the 3 Levels of Cardinality: Getting it Just Right
Tuesday, July 12, 2022 - 1:00 pm EDT

Latest from DevOps.com

Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’
June 30, 2022 | Richi Jennings
Moving From Lift-and-Shift to Cloud-Native
June 30, 2022 | Alexander Gallagher
The Two Types of Code Vulnerabilities
June 30, 2022 | Casey Bisson
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal
Quick! Define DevSecOps: Let’s Call it Development Security
June 29, 2022 | Don Macvittie

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The 101 of Continuous Software Delivery
New call-to-action

Most Read on DevOps.com

What Is User Acceptance Testing and Why Is it so Important?
June 27, 2022 | Ron Stefanski
Chip-to-Cloud IoT: A Step Toward Web3
June 28, 2022 | Nahla Davies
Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New No...
June 30, 2022 | Richi Jennings
DevOps Connect: DevSecOps — Building a Modern Cybersecurity ...
June 27, 2022 | Veronica Haggar
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.