An OSPO should make sure managers understand how to manage secure development, developers know secure coding and how to evaluate third-party software, and anyone shipping into the EU understands the Cyber Resilience Act. The OSPO book points to free OpenSSF courses for each group, though it says specific courses are not required.
Why the OSPO owns training
The OSPO book lists documentation, training and education as a core OSPO activity, saying the OSPO can lead in ensuring that people are qualified to assess open source projects for use in the organization. Its security chapter, written with OpenSSF representatives, says many developers and managers do not know what they need to know about security, and that this gap causes problems.
Three audiences
| Audience | What they need | Course the book names |
|---|---|---|
| Managers | Security terms, risk management, building security into design, protecting environments, setting clear expectations | Security for Software Development Managers (LFD125) |
| Developers | Secure planning, design, coding, testing and release; evaluating third-party software; common vulnerabilities; securing development environments; responding to reports | Developing Secure Software (LFD121) |
| Anyone touching software used in the EU | What the Cyber Resilience Act covers, the roles it defines such as manufacturer or open source steward, and legal responsibilities | Understanding the EU Cyber Resilience Act (LFEL1001) |
The chapter says these specific courses are not required, but that it is important everyone involved in software development gets the right training. The CRA course is a pointer, not legal advice. Ask counsel how the law applies to you.
What developers should learn about dependencies
The chapter's guidance for consuming open source is practical and short. Choose and use components carefully, double-check names to avoid typosquatting, evaluate software with the OpenSSF Scorecard before using it, use multi-factor authentication, secure the build environment, and use automated tools in CI. It also says to use multiple types of tools because each finds different problems, and to enable tools that detect known vulnerabilities in reused components.
Turn that into a one-page onboarding sheet for new engineers. See what to cover in a one-hour open source class for new engineers.
Make training regular, not one-off
The chapter says training should happen regularly, not once, and that teams should know learning about security is recognized. It also suggests teams track and share progress on goals like Best Practices badges or Scorecard results in a way that is open, not blaming.
A simple plan:
- Assign each role the matching course within its first quarter.
- Add a short refresher each year.
- Track completion as one number on your OSPO report.
- Pair every course with one concrete change to a pipeline or process.
Try it yourself
Click through it at your own pace, or open it full screen. Training sticks when it is backed by a visible check like this one.
How Safeguard fits
Safeguard offers policies, gates and guardrails and SBOM and dependency scanning, so the habits taught in training have an automatic backstop. Try gold.safeguard.sh/scan.
Quick check
Are the OpenSSF courses mandatory?
No. The book says the specific courses are not required. It says appropriate training for everyone is important.
Do managers need training too?
Yes. The book says managers should understand how to manage secure development and what their developers need to learn.
Sources
Last reviewed: 19 October 2026.
