Vulnerabilities reach us from several places: dependency scans in CI, the annual penetration test, external researchers, AWS findings, and someone on the team noticing during regular work. This page covers what to do with one.
Where findings come from
Section titled “Where findings come from”- Renovate, OSV-Scanner, and CodeQL run on every PR and on
main. Most findings live and die in GitHub Security without you doing anything: Renovate raises the upgrade PR, OSV-Scanner blocks the merge until you apply it, CodeQL flags a pattern that gets resolved on the fix. See Shipping code for the controls. - Penetration testing. Annual external test. Findings land in the Vanta risk register; see Penetration testing.
- Responsible disclosure. External researchers email
security@changineers.com.au; see Responsible disclosure. - AWS findings. GuardDuty, AWS Config, and similar services raise alerts about misconfigurations or suspicious activity in the AWS environment.
- Internal discovery. You spot something during normal work. Treat it the same as any other finding.
Triage
Section titled “Triage”For automated CI findings, the default is to leave them in GitHub Security and apply the auto-generated remediation (the Renovate PR, the suggested CodeQL fix). You don’t need a Jira ticket unless the fix needs engineering effort beyond what the automation can do.
Open a Jira security ticket when:
- A Renovate upgrade breaks the app and needs code changes.
- A CodeQL finding needs manual code changes to address.
- The vulnerability comes from outside CI: pen test, AWS finding, researcher report, internal discovery.
Set a severity label on the ticket; it determines the target remediation timeline.
Severity and target timelines
Section titled “Severity and target timelines”Set severity when you create the ticket. Use the CVSS score as the starting point, then adjust based on impact in our context: a low CVSS can be a higher concern if it’s exploitable in how we use the affected code, and a high CVSS can drop down if the vulnerable path isn’t reached.
| Severity | Target | Guidance |
|---|---|---|
| Critical | 7 days | CVSS 9.0+. Remote code execution, authentication bypass, sensitive data exposure. Use compensating controls, or block unrelated production deploys, if you can’t ship the fix in time. |
| High | 30 days | CVSS 7.0–8.9. Significant impact, limited blast radius. |
| Medium | 90 days | CVSS 4.0–6.9. Often handled by the next routine Renovate batch. |
| Low | Best effort | CVSS <4.0. Track it; don’t date-gate it. |
If you reassess severity after creating the ticket:
- Upgrade. Reset the timeline from the date of escalation.
- Downgrade. Keep the original timeline; don’t reset back.
Resolution
Section titled “Resolution”A finding ends in one of three ways:
- Fix. Apply the patch, upgrade, code change, or configuration change. Standard path.
- False positive. Close the report in its source of truth (GitHub Security advisory, Jira ticket, or risk register entry) with a note explaining why.
- Exception. The vulnerability is real but doesn’t apply to us. Common cases: the vulnerable code path isn’t reached by how we use the dependency, or the dependency is non-production and the vulnerability isn’t a meaningful risk in that context (e.g. a CSV-parsing flaw in a library only used in tests with hand-rolled inputs).
For an exception, write the reasoning in the same source of truth as the finding when you close it. We don’t schedule re-reviews of exceptions; if the same issue resurfaces in a later scan or report, it goes back through triage.