What does good Secure Software Engineering training look like?

Because I have been so vocal about the lame state of training for developers concerning security, several have asked if I would put together some suggestions for good AppSec Training.

The fundamental attribute of effective Secure Development Training is that it focuses on applying Software Engineering best practices to solve security concerns. Knowing how a tester searches for issues may be entertaining for some, but that is not how to solve the issue. An early warning of this is if there is a mention of making programmers “think like hackers”.

Secure Sofware Engineering requires several secure foundational elements. Logging is a great subject to start with because it serves as a context for conversations around data and security leading to PII and PHI and other concerns.

So here is my list, let me know if you can think of other things, I am sure I did not get them all.

  • Logging
  • Code Review
  • Input Interaction Modeling
  • Defensive Coding
  • Implicit Security Requirements
  • What is the importance of consistency and standards?
  • Change Surface Management
  • Why are reusable modules important in security solutions?
  • Dependency Management
  • Investigating Open Source to assess project viability
  • When to build it yourself or not (ex. Leftpad vs Encryption)
  • Trust Boundaries (ex. how to treat the browser, HTTP, API…)
  • Authentication/Authorization schemes (RBAC, OAuth, Claims, JWT…)
  • Secure Ci/CD – protect your product from malicious change
  • Software Engineering’s role in Incident Response

In exceptional circumstances, some Software Engineers and Architects may be interested in things like Secure System Design/Architecture, Threat modeling and Encryption. Things that could indicate the training neglects Engineering and Craftsmanship solutions to Security is mention of:

  • MITRE ATT&CK Framework
  • Penetration Testing or “Hacking”
  • TOP 10 lists

Neglecting Software Engineering and Craftsmanship leads to heavy recurrence of the same class of vulnerability and the same flaws. This is because they are often hyper localized code corrections. Often, security tickets find a way of shortcutting proper process and scrutiny. The only way to change or prevent these common mistakes is to have good training in the first place, and the right leadership in place to keep the momentum going.

What does good Secure Software Engineering training look like?

Leave a comment