YARA Integration with DefectDojo
YARA Integration with DefectDojo
YARA is an open source pattern matching tool maintained by VirusTotal. It scans files, directories, or process memory against rules that describe text strings, byte sequences, and conditions, and prints the name of each rule that matches along with the path it matched. Rules can carry metadata such as a description, author, reference, or severity, and YARA can print that metadata and the matched strings alongside each hit. DefectDojo imports YARA's plain text output.
YARA Integration with DefectDojo
Our security operations team keeps a curated YARA ruleset and runs it across build artifacts and file shares. The matches were useful, but they lived in text files on whichever host ran the scan. Importing that output into DefectDojo gives every rule-and-file match a finding on the right Asset, with the severity our rule authors recorded, the matched offsets as evidence, and a history that shows whether a match was cleared on the next run.
Why YARA Matters
YARA's strength is that the rules are yours. A team can encode exactly what it wants to find and run it anywhere.
- Rules are plain text, versioned, and reviewed like code.
- The same ruleset can run against endpoints, artifact stores, backups, or forensic images.
- Matches name the rule and the exact file, which makes follow-up concrete.
- YARA has no built-in notion of severity. What a match means depends entirely on the rule, which is why rule metadata matters when results are imported.
Advantages of This Integration
What DefectDojo adds to YARA's text output:
- One finding per rule and file. A rule that matches the same file several times becomes one finding with every matched offset listed, instead of one finding per offset.
- Severity your ruleset controls. A
severityvalue in rule metadata is honored (critical,high,mediumormoderate,low,infoorinformational). Rules without it import as Medium, so nothing is silently dropped to Info. - All metadata kept. Description is shown first, and every other metadata key the ruleset uses, such as author, reference, or date, is written into the description.
- Careful parsing. Metadata is parsed rather than split on commas, so values containing commas or escaped quotes come through intact, and YARA's warnings on stderr never become findings.
- Lifecycle tracking. Reimporting the next scan into the same Test mitigates matches that no longer appear, which gives you evidence that a cleanup worked.
- Shared workflow. Assignment, SLAs, notes, risk acceptance for known-benign matches, and Jira tickets all apply.
How This Integration Works
DefectDojo imports YARA output with the YARA Scan scan type, using UI Import, API Import, or Universal Importer in DefectDojo Pro.
1. Run YARA and save the text output. Two flags decide how much each finding can say:
yara -r -s -m rules.yar /path/to/scan > yara.txt
The -m flag prints each rule's metadata, which is where severity lives if your ruleset records one. The -s flag prints the offset and text of each matched string, which becomes evidence in the finding. Note that -s copies content out of the scanned file into the report, so consider what your rules match before enabling it. Plain yara rules.yar target output, with only rule names and paths, also parses; the findings just carry less detail. A run with no matches prints nothing, and an empty file imports as zero findings.
2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select YARA Scan, and upload the text file. Through 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=YARA Scan"
-F "file=@yara.txt"
-F "product_name=build-artifacts"
-F "engagement_name=Rule Scans"
-F "auto_create_context=true"
With Universal Importer in DefectDojo Pro:
universal-importer import
--defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/"
--scan-type "YARA Scan"
--report-path "./yara.txt"
--product-name "build-artifacts"
--engagement-name "Rule Scans"
--auto-create-context
3. Reimport on a schedule. Send each later run to /api/v2/reimport-scan/ against the same Test so cleared matches are mitigated.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in YARA Output | Notes |
|---|---|---|
| Title | Rule name and path | "Rule matched path" |
| Severity | severity in rule metadata |
Critical, High, Medium (medium or moderate), Low, Info; anything else or absent becomes Medium |
| Description | Rule, file, metadata, matches | Rule description first, then other metadata keys, then each matched offset and string identifier with its text |
| File Path | Scanned path | Paths containing spaces are supported |
| Vuln ID from Tool | Rule name | YARA's identity for the detection |
| Finding type | Static | YARA reads files rather than probing a service |
| Deduplication | Hashcode | title, cwe, line, file_path, description |
Use Cases
Artifact screening before release: A release pipeline runs an approved ruleset against build outputs and imports the results into the product's Asset. A High match blocks promotion until someone reviews it, and the review is recorded as a note on the finding.
Incident response sweeps: During an investigation, responders run a targeted ruleset across affected hosts and import each host's output into its own Test. The team sees which systems matched and tracks cleanup to closure.
Policy checks with custom rules: Some teams write YARA rules for things that are not threats at all, such as forbidden license headers or internal markers that must not ship. Severity in metadata lets those land at Low or Info.
Recurring file share audits: A weekly sweep of shared storage reimports into the same Test, so new matches stand out and resolved ones close.
Operational Tips
- Always run with
-mand record aseverityin rule metadata. Without it, every match lands at Medium. - Use
-swhen evidence helps triage, but remember the matched text comes from the scanned file and will be stored in DefectDojo. - The description is part of the dedupe hash, and it includes metadata and matched strings. Changing rule metadata or matching different strings in the same file can create a new finding rather than matching the old one.
- Keep one Test per host or artifact store and reimport into it, so mitigation reflects a specific scan target.
- Risk-accept known-benign matches with an expiration date, and tune the rule instead of letting the same false positive return every run.
- Tag imports with the ruleset version (for example
tags=rules-2026-10) so you can tell which rules produced a finding.