Security departments used to have the primary responsibility to ensure security goals, but as the pace of development has increased, organizations have shifted security left, which puts some of this responsibility on developers.

Proper educational opportunities, a culture shift towards embracing security, and effective use of tooling where it actually counts are the primary ways to bring about this shift. After all, organizations that provide coaching and training to their developers see a threefold improvement in security finding remediation, according to Cody Betram and Patrick McNeil, senior principal solution architects at Veracode, who discussed security issues in a recent webinar with SD Times.

RELATED CONTENT: What role do developers have in application security?

“As far as what I learned in college didn’t really help in building secure code and I think that most developers would write more secure code if they actually knew how. I think that the challenge is building that knowledge through educational opportunities for developers and not expecting them to learn everything when you point a firehose of e-learning at them or something but giving them very focused, specific things to watch out for,” McNeil said.

This can mean training on the most common CWE types or e-Learning opportunities like Security Labs, where developers can get hands-on practice with real code. However, it’s important to show developers where they should be diverting their attention in the first place. This means identifying what aspects are best for automation and which ones need a human perspective.

Tooling can be very effective at solving issues such as cross-site scripting and SQL injection, but security aspects such as knowing at which points to put authentication in the application or things that require business logic should be prioritized by developers, Bertram said.

“Static analysis for that type of problem is going to be more like an MRI and will say here’s exactly the problem, and all these symptoms are tied to that root problem. Things that a human needs to always do is business logic. You actually have to think about the intended functionality of an application and are there any adverse things an attacker could do?,” Bertram said.

This is where a security champion program – in which a senior developer or those interested in moving into a security profession take the lead within their team’s security objectives – can be an effective measure to increase security.

“I’ve seen customers have success with embedding a security champion in a particular program and giving them a checklist that says ‘Hey, if you’re working on something that has anything to do with authentication or setting up a new microservice those are the times you want to pull in a security team member and you’ll learn a lot from that information,’” McNeil said.

Also essential is the ability to collect metrics to sell the value of security as a ‘feature’ rather than a resource drain. As process changes are put in place, teams need to track the metrics to see if they are really having an impact or not and this is one of the aspects where developers and security teams can work together.

It’s also about quantifying which vulnerabilities need the most attention to enhance cost savings in the form of breach avoidance.

“I recently read that someone shelled out $10 million because someone got a foothold into their network and planted a ransomware piece of malware and encrypted all their files. Then, they paid up to get the decryption key. A command injection getting a foothold into a network that would allow someone to run that type of command? I’m like that’s a 10 million dollar issue!,” Bertram said. “Like it really can be quantified.”

One way to implement incentives to tackle these priorities in an organization where if a developer installed a tool on their IDE and ran a certain number of scans they got points. If they resolved flaws by certain severity, they got more points.

“In the end, the participants had fun with it and saw that there was some real measurable impact for them so it was not only a way to learn but a way for them to get rid of quite a bit of their security debt,” McNeil said.

An additional way to address prioritization is to integrate with the CI/CD pipeline first and do asynchronous scanning just to uncover where the security debt really lies. Then developers can make some priority decisions based on the application.

“Culture is going to have to come from the top down, security is going to be under a lot of pressure to deliver secure code, and development teams are as well, but you kind of have to (from the ground up) remind management that there are 3 ways of DevOps and the third way really is about spotting ways that you can improve the process and iterating, and that includes having time to do security burndowns, to have education opportunities and focus on ways to improve the process moving forward,” McNeil said.