SKF Integration with DefectDojo

SKF Integration with DefectDojo

The Security Knowledge Framework (SKF) is an open source web application that gives development teams security requirements, guidance, and training material for building secure software. It was an OWASP flagship project for many years and is built on the OWASP Application Security Verification Standard (ASVS); the OWASP Developer Guide notes that it is no longer an OWASP project. Teams use SKF to select the requirements that apply to a project or sprint, and SKF can export that selection, including as CSV, which is the format DefectDojo imports.

SKF Integration with DefectDojo

We use SKF at the start of a sprint to decide which security requirements a feature has to meet, and DefectDojo to make sure those requirements don't get forgotten once coding starts. Importing the SKF sprint summary puts each requirement on the Asset as a Finding, with SKF's description of the weakness and its recommended controls. The requirements sit next to the SAST, SCA, and DAST results for the same application, so the security review at the end of the sprint works from one list instead of a spreadsheet and a scanner dashboard.

Why SKF Matters

Scanners find problems in code that already exists. SKF works earlier, when the team is still deciding what the code needs to do.

• Its requirements are organized around ASVS categories such as authentication, access control, communication security, and stored cryptography.
• Each requirement comes with an explanation of the underlying weakness and guidance on how to address it.
• Selecting requirements per sprint keeps the list short enough for a development team to act on.
• An exported checklist on its own has no status. Nobody can tell later which requirements were implemented and which were quietly dropped.

Advantages of This Integration

What we got from bringing SKF exports into DefectDojo:

• Requirements become trackable items. Each row in the export becomes a Finding that can be assigned, commented on, and closed when the team shows the control is in place.
• Design and testing in one place. SKF requirements sit on the same Asset and Engagement as scanner results, so a reviewer can check whether a requirement was implemented and whether a scanner later found a related weakness.
• Clean imports. The parser drops rows with an identical title and description, so a requirement selected twice appears once.
• Reimport for the next sprint. Reimporting an updated export into the same Test closes requirements that were removed from the selection and adds new ones.
• Reporting and audit evidence. Requirements keep their history, notes, and closure dates, which helps when someone asks how security requirements were handled for a release.

How This Integration Works

DefectDojo imports SKF output with the SKF Scan scan type, which reads the CSV sprint summary export.

1. Export the sprint summary from SKF. Select the requirements for the project or sprint in SKF and export them as CSV. The parser reads the header row and maps the title, description, mitigation, and optional date columns (column names are matched case-insensitively). The parser treats a backslash as the escape character, so commas inside values can be written as a backslash followed by a comma, as in the sample export in the DefectDojo repository.

2. Import it. In the UI, open the Engagement for the sprint or release, choose Import Scan Results, select SKF Scan, and upload the CSV. To automate it, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=SKF Scan" \
  -F "file=@skf-sprint-14.csv" \
  -F "product_name=customer-portal" \
  -F "engagement_name=Sprint 14" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "SKF Scan" \
  --report-path "./skf-sprint-14.csv" \
  --product-name "customer-portal" \
  --engagement-name "Sprint 14" \
  --auto-create-context

3. Work the requirements. Assign each Finding to the developer implementing the control, and close it once the control is verified in review or by a test.

Data Granularity: What Gets Imported

Within one CSV, rows with identical severity, title, and description are imported once.

Use Cases

At sprint planning: The team selects the SKF requirements for the features in the sprint, exports them, and imports the CSV into an Engagement named for the sprint. Each requirement is assigned to the developer who owns the related story.

During security review: Before a release, the AppSec engineer opens the Engagement and checks every open SKF requirement against the code and against scanner findings on the same Asset, closing the ones that are met and adding notes to the rest.

For new applications: When a team starts a new service, importing an SKF export gives DefectDojo a baseline of expected controls before any scanner has run, so security work is visible from the first sprint.

For audit preparation: Auditors who ask how security requirements are defined and verified can see each requirement, its owner, and its closure date in DefectDojo.

Operational Tips

• Remember that these Findings are requirements, not detected vulnerabilities. Tag the imports (for example tags=skf,requirements) so they can be excluded from vulnerability metrics and SLA reports.
• Every row arrives as Info, because the export carries no severity. If you want certain requirements to carry an SLA, raise their severity during triage.
• Use one Engagement per sprint or release, with start and end dates that match the sprint, so each export maps to a clear time window and reporting by date stays accurate.
• Keep requirement wording stable between exports. DefectDojo matches rows on their content, so editing a requirement's title or description in SKF can make it appear as a new item on reimport.
• Reimport into the same Test when the selection changes during a sprint. Requirements dropped from the export are mitigated rather than deleted, which keeps a record of the change.
• Close a requirement only with evidence, such as a note linking the pull request or test that shows the control works.
• Because SKF is no longer an OWASP project and is moving repositories, confirm which SKF version your team runs and check that its CSV export still uses the columns listed above.