extuno
What does an Extuno scan report look like?
Every Extuno finding ships with the evidence behind it: the file and line, a plain explanation of why it is dangerous, the recommended action, and the mapped technique. This page walks through a single finding and the machine-readable output you can wire into CI.
What fields does a finding contain?
A finding is the unit of an Extuno report. It is never a bare score. Each one carries the location (file path and line number), a short title, a severity, and a category such as secret, dangerous permission, malware behavior, or obfuscation. It includes a why field that explains the risk in plain terms and a recommended action that tells you what to change.
Most findings also map to a MITRE ATT&CK technique so you can group results by adversary behavior. The exact rule that fired is named, so you can trace the finding back to the catalog in detection rules and adjust how it feeds risk scoring.
Where does the evidence come from?
Findings are produced by three layers and the source field tells you which one fired. Static analysis reads the code without running it, using 1100+ rules including 1000+ leaked-secret and API-key detectors. Dynamic analysis runs the extension or package in an isolated, network-segmented microVM and records the endpoints it contacts, the data it sends, and the API calls it makes. AI code analysis reads the full source and explains a finding, but it stays advisory and never overrides the verdict.
Read more about each layer on static analysis, dynamic sandbox, and AI code analysis.
What does a single finding look like inline?
Here is a leaked-secret finding in plain terms. The scanner matched an AWS access key inside a bundled script:
- Rule: det.secret.aws_access_key
- File: background/api.js, line 142
- Severity: high, category secret
- Why: a live cloud credential shipped in the package can be extracted by anyone who installs it.
- Recommended action: rotate the key, remove it from the source, and load credentials from a server the client authenticates to.
- MITRE: T1552.001 (Unsecured Credentials: Credentials In Files)
The evidence snippet shows the matched value in context so you can grep for and rotate it. See how this maps in secret leak detection.
How do I use the SARIF and JSON output?
The same findings are emitted as SARIF 2.1.0 and as JSON. SARIF drives inline pull-request annotations in your code host, so a reviewer sees the finding on the exact line of the diff. The JSON output is the structured record of the scan, including the rule id, location, severity, and the evidence fields.
For an enforced gate, point the CI step at the scan and set the conditions that should block a build. The gate returns a pass or fail and the list of blocking findings. See the recipes on CI/CD secret scanning; GitHub Action, GitLab CI, and pre-commit setups are supported.
Does the report flag a poisoned update?
Yes. When a version you already scanned changes, Extuno diffs the new release against the previous one and flags a benign-to-dangerous escalation, such as a new exfiltration endpoint or a newly added dangerous permission. This is how a package poisoned through its update channel is caught even when the first release was clean.
A version-delta finding carries the same evidence fields plus the from and to versions. Learn more on version diffing and supply-chain attacks, or browse confirmed cases in the malicious database.
{
"finding": {
"rule_id": "det.secret.aws_access_key",
"severity": "high",
"category": "secret",
"title": "AWS access key shipped in package",
"file": "background/api.js",
"line": 142,
"why": "A live cloud credential in the bundle can be extracted by anyone who installs it.",
"recommended_action": "Rotate the key and load credentials from an authenticated server.",
"mitre": "T1552.001",
"evidence": "const KEY = \"AKIA...EXAMPLE\""
}
}
# SARIF 2.1.0 result
{
"ruleId": "det.secret.aws_access_key",
"level": "error",
"message": { "text": "AWS access key shipped in package" },
"locations": [{
"physicalLocation": {
"artifactLocation": { "uri": "background/api.js" },
"region": { "startLine": 142 }
}
}]
}Frequently asked questions
What is the difference between the SARIF and JSON output?
SARIF is the standard format your code host reads to draw inline annotations on a pull request, so a finding appears on the exact line. JSON is the full structured scan record with every rule id, location, severity, and evidence field. Both describe the same findings; you pick the one your tooling consumes.
Does every finding include a MITRE technique?
Most findings, especially high and critical ones, map to a MITRE ATT&CK technique so you can group results by adversary behavior. Some lower-severity informational findings describe a capability rather than a technique and may not carry one. The mapping is part of the evidence on the finding.
Can I fail a CI build on specific findings only?
Yes. The gate accepts conditions on severities and categories. For example you can fail on any critical or high finding, or on the secret category regardless of severity. The gate returns a pass or fail result and the list of blocking findings so the failure is explainable.
Why does the report show the full secret value?
Extuno doubles as a leak scanner, so a secret finding surfaces the matched value in context. An analyst needs the exact string to grep for it across the codebase and rotate the credential. The value is encrypted at rest; the display is for remediation.
Is the AI explanation part of the verdict?
No. AI code analysis reads the source and explains why a finding is dangerous and how behavior changed across versions, but it is advisory only. It never overrides the static and dynamic verdict, which keeps results reproducible and keeps false positives from inflating a score.