When you find a security issue in another team's service, identify the owner, send them a short report with evidence and a suggested fix, agree a date, and escalate on a published schedule if nothing moves. Do not fix it yourself in their repository without asking, and do not leave it in a shared inbox.
Find the owner first
Ownership is often the hardest part. Check, in order: the CODEOWNERS file, which maps code to people or teams and automatically requests their review on pull requests; the service catalogue; the on-call rota; the most recent committers. If none answer, ask the engineering manager of the nearest team, and record that the service is unowned. An unowned service with a finding is a finding about the organisation.
Write a report that gets read
Keep it to one screen.
- What: the issue in one sentence
- Where: repository, file, version or endpoint
- Why it matters: exposure and what an attacker could do, without alarm
- Evidence: how you confirmed it, a link to the scan result
- Suggested fix: the exact change or version
- Suggested date: based on risk
- Contact: who to ask
Open it in the team's normal tracker and mention the owner directly, not in a general channel.
Match urgency to risk
| Situation | Initial contact | Target |
|---|---|---|
| Active exploitation or exposed secret | Phone or chat, immediately | Same day |
| High risk, reachable, internet facing | Direct message and ticket | Days |
| Moderate risk | Ticket | Next sprint |
| Low risk | Dashboard item | Routine update |
For known exploited vulnerabilities, the CISA catalogue lists due dates for federal agencies as a reference for how short the window can be.
Escalation ladder
Publish the ladder so nobody is surprised.
- Day 0: report to the owner.
- After a week with no reply: remind and include the team lead.
- After two weeks: raise with the engineering manager.
- After a month, or sooner for high risk: raise with the director and record in the risk register.
Each step stays factual. Keep a log of dates.
When the fix is not simple
If the fix needs a breaking upgrade, offer help: pair on it, open a draft pull request, or propose a temporary mitigation. Teams respond to help far better than to demands. If the team cannot fix it, record an exception with a named approver and expiry.
What to avoid
- Naming and shaming in public channels
- Reporting the same finding in three places
- Pushing a change into their repository without agreement
- Closing the loop only when someone complains
Quick check
Can I open a pull request in their repository?
Yes if their contribution rules allow it, and it is a draft that they can review. Tell them first so it does not surprise them.
What if the service has no owner?
Escalate to engineering leadership to assign one, or to retire the service. Record the finding against the risk register until then.
Safeguard's asset discovery helps identify what exists and what has no owner, and a free scan can produce the evidence for your report.
Sources
Last reviewed: 19 October 2026.
