“Software is eating the world.”

It’s an old maxim, but the rapid pace of application development drives the point home with every passing day and with every headline about cyberattacks and software vulnerabilities.

From a cybersecurity perspective, it means that every line of code written by software engineers introduces new security risks. There are scores of programmers working at companies to produce hundreds of applications that let you do amazing things, such as access your bank account from your phone. Unfortunately, programmers aren’t perfect. They can make mistakes when they are coding those amazing applications with very short deadlines.

Those mistakes can be dangerous. For example, structured query language (SQL) injection — which is at the No. 1 spot in the Open Web Application Security Project (OWASP) list of 20 most common vulnerabilities — allows attackers to gain access to database information. That information can include sensitive, valuable business or personal data, such as the 4.2 million credit card and debit numbers stolen from the 7-Eleven network in 2007 — just one of many attacks made possible by this extremely common coding error.

The best approach is for your organization to consider educating software developers on how to mitigate their vulnerable code. But where do you get started? What follows are some top considerations to develop this type of training.

Education Platform 1.0: Lessons Paired With Community

To start, consider creating an education platform with interactive lessons on vulnerabilities across a variety of programming languages and ecosystems. Also, create a community site that can provide a safe and inclusive space for developers to advance their knowledge and understanding of code security.

Make both assets available on one developer-centric page with a name that makes the connection specific, such as Developer Central.

The first version of your education platform can host learning modules that cover either all or a portion of the most common coding vulnerabilities and/or notable attacks — for example, Log4Shell. For example, these are OWASP’s top five:

While the top five vulnerabilities form a solid base, plan to add more modules as time and resources allow. Promote uptake with organic posting and social awareness campaigns for each learning module.

How to Source Your Data

Using in-house resources is a no-brainer. To identify which of the industry’s leading vulnerabilities are most commonly plaguing software developers, you can:

    • Rely on your company’s internal research team (if it has one).
    • Pull in insights from developer forums.

Once the learning module topics are identified, shape the material into outlines. Next, test each module with your company’s internal development team to ensure that developers can understand both what a given vulnerability is and how they can mitigate it.

Incorporate User Feedback

Ensure that your platform not only provides an overview of the security issue but also highlights the following so that it’s easy for developers to follow:

    • Examples of how the issue enables an application to be attacked.
    • A description of the flaw’s impact.
    • Resources and guides on how to fix it.
    • Links to related content, such as relevant blogs and additional learning courses.

Also, link the modules to a GitHub repository where users can ask questions, raise any issues they may find with the content and provide feedback that can be used to update the modules.

Transform In-house Developers Into Champions

Leverage internal learners while designing the learning modules. For example, rely on input from multiple software engineers who are representative of the target audience: namely, developers who aren’t necessarily security experts.

Feedback from developers will help to shape your resource hub. A bonus is that it will turn the developers into secure-coding champions for their teams.

These internal developers will become “hall monitors” who advise colleagues on security. In the best-case scenario, these newly trained security evangelists will adopt the habit of urging teammates to scan their code for vulnerabilities to avoid sending flawed code to deployment or production.

Sidestepping Training Pitfalls

One thing to watch out for when designing technology training: failing to ensure that the user can keep track of their progress.

Your learning platform can address that pitfall by providing a checklist on each module: As the user scrolls down, they can view their progress, clearly tracked with checkmarks on the right-hand side of the page. That way, they never lose their place and can pick up where they left off when they exited the platform.

Note that it’s good practice to render progress graphically: It’s far easier for learners to track their progress by looking at a list of checkmarks, as opposed to having to read a block of text.

What to Aim For in Future Releases

In your first or future learning hub iterations, consider adding these enhancements:

    • Videos in the learning modules. These should depict a vulnerability and demonstrate what the impact of it would look like within an actual line of code.
    • An interactive code experience. This feature requires users to dynamically interact with the content by not just viewing sample code but also typing in their own version of the code, as a way of pushing them to actively engage in the lesson. In this scenario, were they to enter the wrong line of code, they would receive an error message. They would repeatedly be prompted to try again until they enter the code correctly.
    • A badge system. In the beginning, you can host the learning modules as ungated resources, meaning that user data isn’t being captured. In the future, consider transitioning to a gated content model — one where trainees would sign up as users to access the content. As they progress, they’d be able to achieve ever higher levels as security experts for each module they complete.

Ponder what the different levels might entail for trainees in this take on learning gamification. For example, trainees completing bronze or silver levels might receive a T-shirt, while those who achieve gold status as security experts might receive a gift certificate on top of swag.

    • A team of evangelists. A development team that can help validate and/or update the modules is ideal.

Conclusion

Cyberattacks are becoming a greater danger than ever before. It will be a heavy lift to create all the modules that could help developers to fend off those attacks, but given what’s at stake, there’s no choice.

Moving the needle on cybersecurity isn’t a “nice to have”; it’s a must.

Attackers will keep attacking. Given the tight deadlines they work under, programmers will keep making errors. But those programmers are also continuing to learn — a process that developer-centric learning hubs can and should foster.