It’s the perfect time: The code is fresh in developers’ minds, and they’re hungry for quality feedback.
If you could improve only one thing in your software development, what would it be: 1. Your ability to more completely detect security vulnerabilities, or 2. your ability to more rapidly resolve those vulnerabilities once detected?
It’s a trick question. You need to choose option 2, and I’m going to tell you why.
The Three Keys to the DevOps Kingdom
When it comes to adopting the application security practices that most lower risk, the biggie isn’t finding all the software anomalies. Rather, the bottleneck is getting the things you already know about rapidly resolved.
In order to unplug this bottleneck, get secure code flowing and transform an organization’s culture to developer-centric security, you have to build the approach around Gene Kim’s Three Ways of DevOps: namely, flow, feedback and learning.
In Kim’s seminal Three Ways, developers shouldn’t be yanked out of flow. Flow describes how an entire system performs, as opposed to a specific silo of work or a department. The term describes both the macro-level stream as IT works with other departments, such as Development or Operations, as well as how developers or system administrators work on their own. Both the upper level and the lower level represent the flow of IT work as it moves through the organization, delivering business value.
Flow begins from the get-go when requirements are identified — be it by the organization or by IT — are built during development and then move into operations to be delivered to customers in the form of a service. The point of Kim’s practice of flow entails never allowing defects to flow downstream.
But when you consider the individual developer, there are also psychological factors involved in flow, and they lead to a sweet spot where you can maintain the zen of developer flow.
Most folks are aware that the pull request is where developers solicit peer reviews of their code. What many people don’t realize, especially in the security world, is that you can add any number of checks to the pull request. This makes it the ideal place to provide security and quality feedback, because the developer is already asking for feedback from their peers.
That’s because checks are perfectly timed in the pull request: They provide feedback at the right moment in time for the developer to stay in flow. If security feedback is provided too early, while developers are still coding and trying to get the functionality to work, it ruptures their flow. It disrupts the mindset of “get the functionality working.”
But after devs make a code commit and update the pull request, they’re eager to see if their beautiful code passes all the quality and security checks in automated testing. It’s the perfect time to provide feedback, when they’re not trying to stitch new features into the application but are instead getting their code ready for their peers to take a look at.
The pull request is the mechanism by which a developer asks for that feedback. Providing that feedback right there, at that point, in the pull request, is the key to maintaining their flow.
Code pride
It has to do with code pride. There’s a psychological motivation that causes the developer to want that feedback at that point in time. Developers are proud of the code they wrote this morning, and they want their peers to like it, too. That’s what the pull request gets them: Think of it like the adrenaline rush we’ve been trained to get from “Likes” on social media: Pull requests are the thumbs-ups, the peer reviews we’re all hungry for. At that point, if automated checks say, “Hey, your code has this problem,” they’re going to sit up and pay attention. They’re going to care.
Also, at that point, the code is fresh in their mind: They understand how it works, and the feedback will immediately make sense to them, because they just wrote the code that morning. Thus, they can quickly resolve issues.
If you wait to triage the vulnerabilities, and it takes X weeks for that triage to occur, then it turns into a product backlog item. It will be weeks or months later before someone on the team gets to work on the issue.
It might not even be the developer who wrote the original code who works to remediate it. Even if it is the original author, by that time, s/he might have forgotten what that code was supposed to do.
That, by the way, is why you should avoid — like the plague — service-level agreements (SLAs) greater than a day. They’re actually harmful. The same day you wrote the code is the quickest time you can fix it. If you build up a pile of issues, it takes 10x more energy to fix them, and the pile will just keep growing. You never get out of that mode.
Let’s go back to that question I first posed. Namely, What do you want to spend your time doing? 1. Hunting for more and more and more code deviations that will never get addressed, instead merely getting glommed on top of the crud pile? Or 2. Resolving the bugs you’ve found, quickly and efficiently?
It’s clear to see why, hands-down, you should opt for No. 2.
Power to the pull request!
Bio: Larry serves as DevSecOps Transformation Architect at Contrast Security. Larry’s work has empowered 600 development teams to take ownership of the security of their software. He embodies a rare combination of deep cybersecurity background with current software development experience. He was a founding Director at Carnegie Mellon’s CyLab and co-led the launch of Build-Security-In initiative but is also the author of a dozen or so open-source projects, one of which gets a million downloads per month, and all of which utilize the approach he advocates for.
