Security training gives developers the knowledge they need to write and review safer code, but once training is complete, how do organizations know whether those skills are making it into the development process?
SecureFlag’s new SDLC Metrics feature matches each code commit with the author’s training records, so organizations can see whether the developer who wrote the code was trained to code securely on the technology involved.
SDLC Metrics matches each commit in a team’s code repository with the author’s SecureFlag training records. For each relevant commit, it identifies the developer who made the change and the technologies involved. It then checks whether that developer had completed relevant SecureFlag training when the commit was made.
Instead of seeing only who finished a course, teams can see how much of the code being committed comes from developers who have done the training and where further learning may be useful. It turns training into a measurable part of the development process.
The process fits into the development workflow teams already have. A job runs inside the CI/CD pipeline, sending commit data to SecureFlag to be matched with developer training records.
Here’s what happens:
Add SDLC Metrics to the pipeline: The SecureFlag job is added to the CI/CD pipeline for the repository being measured.
Read the commit history: The job reads the repository’s commit history and identifies the developer behind each change and the technologies involved, such as Java, Python, or Node.js.
Match commits to training. SecureFlag receives the commit information and checks the developer’s training records to determine whether they had completed relevant training for those technologies when the commit was made.
Update the metrics. Each time the pipeline runs, it processes only new commits, and the results appear in SecureFlag dashboards.
Changes that don’t involve a recognized technology, such as documentation or certain configuration changes, are skipped so the metrics focus on relevant code contributions.
After integration, each run processes new commits, keeping the metrics current without creating duplicate data.
For setup instructions and configuration examples, see the SDLC Metrics quick guide.

An important part of SDLC Metrics is when training was completed. A developer who completes a course today may not have had that knowledge when writing code last month. For this reason, SDLC Metrics compares the date of each commit with the date the author completed the relevant training.
It’s a more accurate measure of training coverage across the development process and can also show where additional training may be useful. For example, if developers commit code in a particular technology without completing training on it, that technology is a good place to start.
Source code is never sent to SecureFlag. The collection happens entirely inside the organization’s own CI environment, and only a small amount of commit information leaves it:
The commit identifier
The commit date
The author’s email address, used only to match the commit to a SecureFlag user
The names of the technologies involved
SDLC Metrics never collects source code, file contents, file names, or commit messages.
Developer security training is meant to help people make better security decisions when they write code. With SDLC Metrics, organizations can see whether that training applies to the code their teams are producing.
Matching training records with code commits gives organizations a measurable link between training and the code that ships. Teams can see how much of their code was written by trained developers and which technologies have the lowest training coverage so that they can base training decisions on data.

SecureFlag is a hands-on security training platform with coding labs in real development environments. Developers practice secure coding in the languages and frameworks they use, and organizations can track training progress across their teams.
SecureFlag also offers ThreatCanvas, an automated threat modeling solution that helps teams identify and address security risks earlier in the development lifecycle.
Along with SDLC Metrics, these capabilities help organizations keep developer training an ongoing part of secure software development and measure how it applies to the code their teams ship.