The DevSecOps lesson closed with an uncomfortable idea: no pipeline replaces the judgment of whoever writes the code and approves the pull requests. A SAST scanner detects a known pattern, but it is a developer who decides to validate an input, who recognizes that a price must not come from the client, who writes a test for a threat from the threat model. Security, ultimately, is produced by people. That is why the human factor is not an add-on to the security program: it is its foundation. In this lesson we design BazarNube's training and awareness program, with security champions, secure coding training, and gamification, and we frame it within SAMM's Education & Guidance practice.

1. Why the human factor is decisive
2. Secure coding training for developers
3. Security champions: distributed security
4. Gamification: learning by attacking (Juice Shop, CTFs)
5. General awareness and phishing awareness
6. Metrics for an awareness program
7. BazarNube's awareness program
8. Common mistakes and tips
9. Exercises
10. Conclusion

Most Top Ten vulnerabilities are born of a human decision: concatenating SQL instead of parameterizing, forgetting an authorization check, trusting a piece of client data. Tools help catch patterns, but not every decision is a detectable pattern. A business-logic or design flaw (A04) is rarely found by a scanner; it is avoided by a developer who has learned to think like an attacker.

Moreover, awareness is what makes the rest of the program work. A DevSecOps pipeline with gates assumes a team that understands why they exist and does not sabotage them; a threat model assumes people capable of imagining threats. Without culture, tools become obstacles that people learn to dodge.

Generic "security awareness" training (do not click strange links) is necessary for everyone, but insufficient for those who build software. Developers need secure coding: learning to write code that resists attacks, with examples in their own stack.

Characteristics of effective secure coding training:

• Stack-specific: examples in React, Node/Express, and Java/Spring—what the team actually uses—not generic slides.
• Based on the Top Ten and ASVS: it teaches how to prevent the real risks and meet verifiable requirements.
• Hands-on, not just theoretical: you learn by fixing vulnerable code, not by listening.
• Continuous: an annual session is forgotten; better to have frequent bite-sized sessions tied to real backlog findings.
• Contextual (just-in-time): the best moment to teach about injection is when SAST flags one in that person's PR.

A good source of content is the OWASP Cheat Sheets (concise guides by topic) and the WSTG, which we will see cataloged in 07-05.

A central security team never scales to dozens of development teams. The solution promoted by both OWASP and SAMM is security champions: developers within each team who take on an additional role as a security point of reference.

A security champion:

• Is not a full-time security expert, but a developer with interest and a bit of extra training.
• Is the bridge between their team and the central security team.
• Helps review PRs with a security focus, facilitates threat modeling for their team (recall who reviewed the checkout model in 07-02), and triages the pipeline findings.
• Spreads the culture from within, with the credibility of a peer.

The champions program is one of the highest-return investments for raising maturity, precisely because it scales the culture.

You learn far more by breaking a system than by reading about how it is broken. Gamification turns learning into an attractive challenge:

• OWASP Juice Shop: a deliberately vulnerable, modern web application (JavaScript), with dozens of challenges that cover the entire Top Ten. The learner exploits real vulnerabilities in a safe environment and earns points. Ideal for internal workshops.
• CTF (Capture The Flag): competitions where teams solve security challenges to capture "flags." They foster collaborative learning and healthy competition.
• Vulnerable environments: WebGoat (also from OWASP), DVWA, and similar, to practice specific techniques.

Gamification has an extra cultural benefit: by stepping into the attacker's shoes, the developer internalizes why the defenses they used to see as bureaucracy matter.

Beyond those who program, the whole organization handles information and access. General awareness covers everyone, including non-technical roles (product, sales, leadership):

• Basic hygiene: password management, MFA, locking devices, not reusing credentials.
• Phishing awareness: phishing remains one of the main entry vectors. At a high level, a program includes training on how to recognize suspicious emails and controlled phishing simulations to measure and improve. The simulation should be used to educate, never to punish or shame: a punitive culture makes people hide mistakes instead of reporting them.
• Easy reporting: a clear, frictionless channel to flag something suspicious; reporting should be easy and well received.

What is not measured cannot be improved. A serious program defines metrics, avoiding purely vanity ones (hours of training) in favor of those that reflect behavior change and risk reduction.

Outcome metrics (are the real flaws going down?) are worth more than activity metrics (how much training did we give?). The ultimate goal is for the trend of reintroduced vulnerabilities to decline over time.

At BazarNube, security was de facto handled by Lucía in her spare time. The program formalizes and distributes that responsibility, explicitly framed within the Education & Guidance practice of SAMM's Governance domain.

Security champions structure:

Training plan (first year):

The program is not a one-off course but a cycle that feeds back on the metrics and the real findings, raising the maturity level year after year.

• Generic, annual training. A one-hour talk once a year does not change behavior. Prioritize stack-specific, continuous, contextual training (just-in-time on real findings).
• Punitive phishing. Using simulations to single out culprits destroys trust and makes people hide incidents. Use them to educate and to measure the trend, not to punish.
• Champions without time or support. Naming champions and not giving them hours, training, or recognition dooms the program. The role needs explicit backing from leadership.
• Measuring only activity. "We delivered 200 hours of training" does not say whether the team is more secure. Measure outcomes: are reintroduced flaws going down? Is the time to fix improving?
• Tip: tap into curiosity. A Juice Shop workshop where people actually "hack" generates more learning and enthusiasm than ten presentations. Engagement is the best multiplier of training.

Exercise 1. BazarNube has a central team of two people and six development teams. Propose a mechanism to scale the security culture without hiring, and explain its logic.

Exercise 2. Classify each metric as activity or outcome and indicate which is more valuable: (a) hours of training delivered, (b) trend of injection vulnerabilities per quarter, (c) click rate in phishing simulations.

Exercise 3. SAST flags a SQL injection in a junior developer's PR. Describe how to seize that moment as a just-in-time training opportunity.

Solution 1. A security champions program: one developer per team (six in total) receives extra training and acts as a point of reference and bridge with the central team. The logic is that a central team does not scale to six teams, but it can enable six champions who spread the culture from within, with the credibility of a peer and deep knowledge of their own product. It multiplies the reach without multiplying headcount, and it is the practice SAMM recommends.

Solution 2.

• (a) Activity. (b) Outcome. (c) Outcome.
• The most valuable is (b): it measures whether the training actually reduces the reintroduction of the flaw, which is the ultimate goal. (a) only measures effort, not effect.

Solution 3. Instead of merely rejecting the PR, the security champion or a reviewer comments on the finding explaining why it is vulnerable, links the injection-prevention Cheat Sheet, shows the fix with a parameterized query, and, if appropriate, asks for a test that covers the case. That way the learning happens in the real context, on that person's code and at the moment it is most memorable, rather than in an abstract talk months later.

The human factor is the foundation of the whole program: tools catch patterns, but it is people who make the design decisions and who make gates, threat models, and pipelines work instead of getting in the way. We have designed BazarNube's program with stack-specific secure coding, security champions who scale the culture, gamification with Juice Shop and CTFs, and outcome metrics, all framed within SAMM's Education & Guidance practice. Throughout these lessons, many tools and resources have appeared by name. In the module's final lesson, 07-05, we bring them together in an overview organized by category and define the recommended security stack for BazarNube, thus closing the best practices before we move on to putting them into play.