DevSkim Integration with DefectDojo

DevSkim Integration with DefectDojo

DevSkim is an open source static analyzer from Microsoft. It uses a library of pattern-based rules to flag risky code across many languages in a single pass: banned C functions, weak or broken hash algorithms, non-cryptographic random number generators, dynamic code evaluation of untrusted input, and similar dangerous API use. DevSkim ships as IDE extensions and as a command-line tool distributed as a .NET global tool, and the CLI writes SARIF by default, which is the format DefectDojo imports.

DevSkim Integration with DefectDojo

We added DevSkim to our pipelines because it is fast, language-agnostic, and catches the kind of crypto and API mistakes that slip past code review. What it does not do is remember anything between runs. Importing DevSkim SARIF into DefectDojo gives each finding a file, a line, an owner, and an SLA, and keeps DevSkim's results separate from the other SARIF tools we run against the same repositories. When a developer replaces an MD5 call, the next reimport closes the finding instead of leaving someone to compare two SARIF files.

Why DevSkim Matters

Many security defects are not subtle logic flaws. They are a call to a function that should never be used, or a hash algorithm that stopped being acceptable years ago.

• DevSkim's rules target exactly those patterns, with guidance pages explaining each rule and what to use instead.
• One tool covers a polyglot repository, so C, Python, JavaScript, and other languages can be checked in a single run.
• It is lightweight enough to run on every commit, and the same rules can run in the developer's IDE.
• Many results include suggested fixes, such as replacing a weak hash with SHA-256 or SHA-512.
• On its own, SARIF output is a per-run file. Nobody can tell from it whether an issue is new or has been open for months.

Advantages of This Integration

What we gained by sending DevSkim results through DefectDojo:

• A scan type of its own. DevSkim reuses DefectDojo's SARIF parsing but registers its own scan type, DevSkim Scan, so its findings stay distinct from other SARIF producers scanning the same code.
• Source-position deduplication. Findings are matched on title, CWE, line, file path, and description, the right key for a finding tied to a location in code.
• Lifecycle across commits. Reimporting into the same Test mitigates findings that disappeared, adds new ones, and reactivates any that return.
• Fix guidance carried over. DevSkim's suggested fixes land in Mitigation and the rule's guidance page lands in References.
• Suppressions respected. SARIF results that carry suppressions are imported as false positives and inactive, so they do not count against SLAs.
• Shared workflow. Findings can be assigned, risk-accepted, pushed to Jira, and reported on alongside every other tool's output for the Asset.

How This Integration Works

DefectDojo imports DevSkim results with the DevSkim Scan scan type, which expects SARIF.

1. Install DevSkim and write a SARIF report.

dotnet tool install --global Microsoft.CST.DevSkim.CLI
devskim analyze -I ./src -O devskim.sarif -f sarif

SARIF is the default, so -f sarif can be omitted. The text and vs output formats are not supported by the parser. Without -O, DevSkim writes to standard output. The path you pass to -I shapes the file paths in the report, so run it from a consistent location in every pipeline.

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select DevSkim Scan, and upload the SARIF file. To automate it with the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=DevSkim Scan" 
  -F "file=@devskim.sarif" 
  -F "product_name=payments-api" 
  -F "engagement_name=CI" 
  -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 "DevSkim Scan" 
  --report-path "./devskim.sarif" 
  --product-name "payments-api" 
  --engagement-name "CI" 
  --auto-create-context

3. Reimport on every build. Send later reports to /api/v2/reimport-scan/ against the same Test so fixed findings are closed and history stays in one place.

Data Granularity: What Gets Imported

DevSkim also writes its own DevSkimSeverity property (Critical, Important, Moderate, ManualReview). The parser does not read it, so a rule DevSkim grades Critical, such as the weak hash rule, imports as High because its SARIF level is error.

Use Cases

In a CI/CD pipeline: Each merge to main runs devskim analyze and reimports the SARIF into a Test named for the repository. New banned-function or weak-crypto findings show up as new, and fixed ones are mitigated automatically.

Alongside other SARIF tools: A team runs DevSkim, Semgrep, and CodeQL on the same repository. Because DevSkim has its own scan type, its findings can be filtered, measured, and reimported independently instead of mixing with the other tools' results.

During a crypto cleanup: A security team planning to retire MD5 and SHA-1 filters on the cryptography tags and rule IDs to see every occurrence across Assets, assigns them by team, and tracks progress against an SLA.

For legacy C and C++ code: DevSkim's banned function rules give a quick inventory of unsafe string and memory calls, which can be risk-accepted where a rewrite is not planned or ticketed to Jira where it is.

Operational Tips

• Remember the severity gap. Findings use the SARIF level, not DevSkim's own grade, so adjust severity during triage if you rely on the Critical rating for specific rules.
• Expect empty CWE fields. Filter and report on rule ID or tags instead.
• Run DevSkim with the same -I path in every pipeline. File paths feed the deduplication hash, so a changed root makes every finding look new.
• DevSkim treats printf as a banned C function, so C codebases can produce many findings on the first run. Use minimum_severity or risk acceptance for patterns you have decided to accept.
• Tag imports with the repository and branch (for example tags=payments-api,main) to separate results in dashboards.
• Use one Test per repository and reimport into it, rather than creating a new Test per run, to keep a clean open-to-mitigated history.