Coverage and assessment scope
Understand code, dependency, secret and configuration assessment, and what a result can tell you about the software you selected.
Look beyond one category of issuePermalink to Look beyond one category of issue
A repository can carry security risk in application code, dependencies, exposed credentials and deployment configuration. Relane brings these assessment areas into a common result so you can review the evidence and affected locations without confusing different kinds of issues.
| Assessment area | What to look for in a result |
|---|---|
| Application code | Potentially unsafe behavior and its supporting code context. Evidence and validation determine whether an issue is confirmed. |
| Dependencies | Vulnerable dependency versions identified from the package information available in the selected repository. |
| Secrets | Potential exposure of credentials or other sensitive values. Investigate and rotate an exposed credential; deleting a line is not enough. |
| Infrastructure as code | Security-relevant configuration in supported infrastructure files, where applicable to the selected scope. |
| Container configuration | Security-relevant issues in supported container build configuration. This is not a claim that a running deployment was tested. |
Coverage is specific to the assessment
Know which code the result describesPermalink to Know which code the result describes
Select the repository and branch or ref you intend to review. After the scan, check the revision and scope recorded with the result. Findings belong to that assessment, not automatically to every branch, a newer commit or a running deployment.
- Check the repository, branch or revision before starting.
- Keep the recorded revision, assessed scope and limitations with the result when sharing it.
- Use the scan's actual completion state and coverage rather than assuming that starting a scan guarantees a complete assessment.
- Reassess changed code when you need evidence about a newer revision.
Coverage and findings answer different questionsPermalink to Coverage and findings answer different questions
Findings tell you which issues were established. Coverage tells you how much confidence to place in the assessment of the selected scope. A scan can report useful confirmed findings while also reporting limitations. It can also return no confirmed findings without establishing adequate coverage.
| Result | Appropriate next step |
|---|---|
| Confirmed findings with adequate coverage | Prioritize and remediate the findings within the recorded assessment scope. |
| Confirmed findings with limited coverage | Act on the established issues and plan follow-up for the unassessed or incomplete areas. |
| No confirmed findings with adequate coverage | Record that no confirmed issues were reported in that assessment, not that the software is vulnerability-free. |
| No confirmed findings with limited coverage | Resolve the stated limitation or perform an appropriate follow-up before treating the result as reassuring. |
Evidence changes what can be claimedPermalink to Evidence changes what can be claimed
A confirmed finding has met the evidence requirements for its issue type. Some issue types can be established from repository evidence; others need further validation. A candidate that still needs validation remains a lead, even if its potential severity is high. Review the finding's evidence rather than assuming every confirmed item was demonstrated against a live application.
Repository assessment is not permission to test a live targetPermalink to Repository assessment is not permission to test a live target
Connecting a repository authorizes the configured repository workflow; it does not authorize testing any deployed application associated with that code. A pentest engagement needs an explicitly authorized target and scope. Its report should be read against that scope, separately from a repository scan.