Solar Appscreener Integration with DefectDojo

Solar Appscreener Integration with DefectDojo

Solar appScreener is a static application security testing (SAST) product from Solar, the cybersecurity company of Rostelecom. It analyzes application code across many programming languages and reports weaknesses such as hardcoded credentials, injection flaws, and information leaks, each with a description, recommendations, reference links, and the file and line where it was found. Scan results can be exported as CSV, and DefectDojo imports the Detailed_Results.csv file from that export.

Solar Appscreener Integration with DefectDojo

We use Solar appScreener to scan our code, and DefectDojo is where its findings get owners and deadlines. A SAST export on its own is a long table that someone has to compare by hand against last month's. Imported into DefectDojo, each row becomes a Finding on the Asset that owns the repository, pinned to a file and line, deduplicated against previous scans, and measured against our SLAs. Code findings from appScreener then sit next to our dependency, container, and DAST results for the same application.

Why Solar Appscreener Matters

Static analysis finds weaknesses before code ships, when they are cheapest to fix.

• appScreener reports each issue with the vulnerable file and line, which developers need to act quickly.
• Findings include written recommendations and links to sources such as OWASP and CWE, so the fix guidance travels with the issue.
• The export records the language of each finding, which helps route work in polyglot codebases where different teams own different languages.
• Some rows include a Trace value listing source locations, which reviewers can consult in appScreener when a finding needs deeper analysis.
• Like any SAST tool, appScreener produces results that need triage. Without a platform to remember decisions, the same false positives are reviewed again on every scan.

Advantages of This Integration

What we gained by sending appScreener results through DefectDojo:

• Location-based deduplication. DefectDojo hashes Solar Appscreener findings on title, file path, line, and severity, so a weakness reported at the same place in the next scan is recognized as the same Finding.
• Reimport lifecycle. Reimporting a new export into the same Test mitigates findings that no longer appear after a fix and adds new ones.
• Triage that sticks. Findings marked false positive or risk-accepted keep that status in DefectDojo, so the team reviews new results instead of the whole list.
• SLA tracking. appScreener severity levels carry straight into DefectDojo, so code findings follow the same SLA rules as other scanners.
• Developer handoff. Findings can be assigned, commented on, and pushed to Jira from DefectDojo with the file, line, and recommendation attached.

How This Integration Works

DefectDojo imports appScreener results with the Solar Appscreener Scan scan type. The parser reads Detailed_Results.csv by column name, so the header row must be present.

1. Export the scan results from Solar appScreener and locate Detailed_Results.csv. Its columns include Vulnerability, Language, Description, Recommendations, Links, File, Line, and Severity Level.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Solar Appscreener 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=Solar Appscreener Scan" \
  -F "file=@Detailed_Results.csv" \
  -F "product_name=payments-web" \
  -F "engagement_name=SAST" \
  -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 "Solar Appscreener Scan" \
  --report-path "./Detailed_Results.csv" \
  --product-name "payments-web" \
  --engagement-name "SAST" \
  --auto-create-context

The file is read as UTF-8, and the parser expects comma delimiters with double-quoted fields, which is how the export is written. If someone opens the CSV in a spreadsheet and saves it again, check that the encoding and quoting survived before importing.

3. Reimport for each new scan. Send later exports to /api/v2/reimport-scan/ against the same Test so fixed findings are closed automatically.

Data Granularity: What Gets Imported

Every row becomes its own Finding. The parser does not merge rows within one file, so DefectDojo's hashcode deduplication handles repeats.

Use Cases

In a release pipeline: Each release candidate is scanned with appScreener and the export is reimported into a Test for the repository. The AppSec team reviews only new findings, and a release gate checks DefectDojo for open Critical findings.

For triage at scale: The first import of a large codebase can produce hundreds of findings. Triage happens once in DefectDojo, with false positives marked and real issues assigned, and that work carries forward to later scans.

For audit evidence: Code findings keep their discovery date, owner, and closure date, which helps demonstrate a secure development process to auditors.

Across scanners: SAST results from appScreener appear on the same Asset as SCA and DAST findings, so a single report covers the application. When two tools flag the same weakness, reviewers can see both reports side by side and close them together.

Operational Tips

• Check the Severity Level values in your export. The parser copies them directly, so values must match DefectDojo's names (Critical, High, Medium, Low, Info) for SLAs and filters to work as intended.
• Line numbers are part of the dedupe hash. Code edits above a finding shift its line, which can make it look new on the next import. Review those pairs during triage and close the old one if it is the same issue.
• The appScreener Status column isn't imported. Record triage decisions in DefectDojo, or filter the export before import if you want appScreener-side statuses respected.
• CWE is not mapped from the CSV, even though the Links column often contains CWE URLs. Add the CWE during triage if your reporting depends on it.
• Use one Test per repository and branch, and reimport into it, so fixed findings are mitigated rather than left open in an old Test.
• Set minimum_severity on import (for example minimum_severity=Medium) while the team works through an initial backlog, and lower it once the higher-severity findings are under control.
• Tag imports with the branch or build (for example tags=main,build-512) to tie findings to the code version that produced them.