Whiteboard Wednesday:

Moving Left in the SDLC

April 04, 2018

In this week’s Whiteboard Wednesday, Mark Hamill, Senior Product Manager for Application Security Products, outlines why businesses can no longer afford for web application security to be the responsibility of a single team, rather than a shared initiative across security, IT operations, and development teams. The secret to running both quickly and securely? Shifting the responsibility of application security left in the software development lifecycle (SDLC).

Want to learn how to start shifting left and adopting DevSecOps practices? Check out our whitepaper, A Step-by-Step Guide to Shifting Left and Embracing a True DevSecOps Mentality.

Video Transcript

Hi, and welcome to this week's Whiteboard Wednesday. I'm Mark Hamill, Senior Product Manager for Application Security Products at Rapid7. Today, I'd like to talk about application security testing, and specifically how dynamic application security testing, or DAST, can help you secure your web apps. DAST involves using a purpose built engine, which automatically crawls a web app in real time just as a user would, discovering the directories, pages, and elements which can be potentially vulnerable to attack. Web application attacks are the number one source of breaches as per the 2017 Verizon Data Breach Investigations Report. Often, application vulnerability assessments are done as part of a final check before deploying apps into the public domain. This can create a bottleneck of bugs, which all need to be investigated, prioritized, and potentially fixed, all of which can delay a release. Any piece of software which has more code than a simple Hello, World program has bugs. And it doesn't make sense to wait til the eleventh hour to start looking for them.

Show more Show less

The software development lifecycle, or SDLC, describes the phases a software project will pass through from conception and design to development and ultimately delivery and maintenance. When we talk about moving left in the SDLC, we mean that looking for vulnerabilities should be an integral part of the development process right from the start. Pushed a new feature today? Run a scan. Incremental bug fixes? Run a scan. Implemented support for a new language? You get the idea. While this generates overhead, there are various ways in today's modern development environments to automate scans, pull down results, and open bugs in your favorite bug tracking tool. Now the flip side is that you'll see more bugs. But having that information early lets you make decisions without instantly compromising deadlines. A bug you find early doesn't have to be a blocker. And a tight deadline to release based on a prior commitment can result in bug being launched that ultimately becomes a breach.

Inevitably, there is a cost to scanning your pre-deployment code base more often. And that cost is more than just cold hard cash. There are dev efforts, systems to be built and tuned, more bugs in your back log, and on the service much more work to do. Consider it an investment though, rather than reparation. The cost of recovering from a public breach will stack up way higher than just cash. And it's never a good look for your customers to hear on the news their data has been stolen, particularly if it was easily avoidable breach. To get the most from your AppSec program, look for opportunities to imbed security assessment as a regular component of the software development lifecycle. That way, you can discover vulnerabilities as they arise, not as you launch. That's it for today's Whiteboard Wednesday. We will see you next week.

Whitepaper:

A Step-by-Step Guide to Shifting Left and Embracing a True DevSecOps Mentality

Read More

Free Trial

InsightAppSec is Rapid7's cloud-powered DAST tool with powerful crawling and attack capabilities.

Try for 30 Days