The Software Development Lifecycle (SDLC) seems innocuous enough; it's a process, and us software people all come together to make the magic happen and ship off all those digital goodies society cannot live without.

Except... if you've ever been part of a software development project, you'll know it's usually a gauntlet, with many quests to conquer and dragons to slay. It's fun for a while, but burnout is real, and the demand for software has us all working at the speed of light at the best of times, especially the development team.

Now imagine they're thrown another must-do task... responsibility for security in the project elements they touch. This, at worst, may cause the house of cards to come crashing down for some individuals, but the more realistic scenario is that it's simply not made a priority, and the issues deemed more pressing to get over the line take precedence. And when most developers aren't trained to code securely (especially if their managers are not prioritizing security, either), it's little wonder we see frequent data breaches, flawed app releases, and some serious churn among security professionals reaching breaking point under an avalanche of buggy code.

Developers need an AppSec advocate.

When taking in the scenario above, you can understand why security is put in the "too hard" basket during the coding process, and left to the security team to work out. Too many competing deadlines, not enough training, and no real reason to care about security with everything else going on. However, there is simply too much demand for code for this status quo to continue. And that's where super-elite developers can stand out from their peers, learn new skills, and most importantly, build safer code.

However, it's important to remember that it's not all on the shoulders of developers to manage software security - that's still the domain of the AppSec team (who, when working with security-aware developers, will have more breathing space instead of fixing common bugs on repeat). A functioning DevSecOps process requires every member of the team to have the support and tools they need to share the responsibility for security, and the right kind of training is paramount. Balancing the right suite of tools and training requires the insight of AppSec professionals willing to work closely with devs to inspire them and drive positive change.

Disruptive training is more annoying than it is effective, and anything repellent to developers isn't going to work. An IDE or issue tracker-integrated solution focused on bite-sized knowledge is one alternative, and it gets the right information in front of them, at the very moment it is needed.

Here's how it works in action:

Just-in-Time, not "just in case".

Contextual, hands-on learning is by far the most effective way to train, with bite-sized chunks delivered right when they make the most sense. This is sometimes referred to as "Just in Time" (JiT) training, and it's very powerful for developers learning secure coding.

With origins in Toyota's lean manufacturing principles, JiT training is designed to activate on a need-to-know basis, in context, when it matters most. Has a developer just written something that looks to have improper permissions? What if a small back door was opened that allowed an attacker to remotely execute code? It will be far more memorable if developers can access knowledge right as they need it, rather than trawling back through documentation in Confluence, or Googling something that was touched on in training.

Just-in-Time is the antithesis of "just in case" learning; while the latter is the more common way of imparting knowledge, it's simply not efficient. We must make it easier for developers to engage with secure coding best practices, and see the benefit in upskilling for their career while maintaining focus on the key objectives they are working on right now.

Stop making developers chase the training.

We already know there is too much going on in a workday, so what incentive do developers have to schlep off to a classroom, or context-switch to go through five steps to access static theory-based training?

The general consensus is that whatever most organizations are doing is not terribly effective if the amount of vulnerabilities causing data breaches is anything to go by. The 2020 Data Breach Investigations Report from Verizon specified that 43% of data breaches could be attributed to web vulnerabilities. Developers are not receiving effective training; not in tertiary education, nor as part of workplace upskilling measures. If they were, common vulnerabilities like SQL injection and old-school path traversal would not be exploited for significant data paydirt, and the cybersecurity skills shortage wouldn't be out of control.

So, knowing this is the current climate in which developers receive training and get acquainted with security, why are we surprised at the poor outcome? It might just have an effect -- a positive one -- for both the developer and organization to ensure a smoother, more integrated and less jarring training experience, where it is accessible in the spaces they actually work in, like Jira, GitHub, and in the IDE. The industry simply needs to move forward and make security awareness much easier, in an environment where it's no longer a luxury.

Ready to secure the development workflow?

Security-aware developers are revered for their skills, and the protection they can offer organizations right from the code-building stage. Security is no longer optional, especially with GDPR fines, PCI-DSS compliance regulations, NIST governance... and the possibility of being sued in a big old multi-million-dollar class action, a'la Equifax.

An integrated approach might be the catalyst to start winning over developers with less disruptive learning, and create some pathways for more in-depth courses, training up security champions, and generally inspiring that shared responsibility we need to keep the world's data safe and sound.

Download integration tools for Jira and GitHub now, and let us know what you think.