A first AppSec hire at around 50 engineers should automate the repetitive steps first: routing each alert to an owner, grouping duplicates, dismissing clearly low-risk categories, and tracking aging. Keep judgment calls, such as exceptions and exploitability disputes, with a human until the data shows the rules are right.
The trap for a first hire
A new AppSec engineer inherits a backlog and a Slack channel. The temptation is to read everything and become the human filter. That feels productive for a month and then becomes the whole job.
The better first quarter is about removing yourself from the routine path so you can spend time on the cases that need an expert.
What to automate, in order
- Routing. Every alert gets an owning team without a human decision. This needs an ownership map first, so build that in week one.
- Deduplication. One advisory across many repositories should be one work item. See group alerts into one work item.
- Low-risk dismissal. Pick categories where the cost of being wrong is small and apply rules with a review date.
- Aging and escalation. An alert that has sat past its clock gets a nudge, then a manager notification.
- Reporting. A weekly summary that nobody has to assemble.
Where rules help and where they do not
Platform rules can do part of step three. GitHub's auto-triage rules apply before notifications, let you dismiss or snooze by metadata such as severity, package name, or CWE, and keep auto-dismissed alerts visible and reopenable. The same documentation warns about a real tradeoff: a preset that dismisses malware alerts for packages flagged in all versions will also dismiss a truly malicious dependency that a contributor adds. Read each rule's failure case before enabling it.
Keep these with a human at first:
| Decision | Why it stays manual |
|---|---|
| Accepting risk on a reachable issue | Needs business context |
| Disputing exploitability | Needs code knowledge |
| Changing the policy windows | Affects every team |
| Closing alerts on a vendor product | Needs vendor contact |
Use public signals as inputs, not verdicts
Two inputs are free and widely used. The Known Exploited Vulnerabilities catalog is CISA's list of vulnerabilities seen exploited in the wild. EPSS, published by FIRST, estimates the probability a CVE will be exploited in the next 30 days and is updated daily. FIRST is explicit that EPSS is not a complete risk score, since it does not measure impact or your environment. Use both to order work, then add your own context. The longer comparison is in CVSS vs EPSS vs KEV.
Measure the automation
After each rule goes live, sample ten of its dismissals a month and check whether you would have made the same call. If you disagree in more than a couple, tighten the rule.
Try it yourself
Click through it at your own pace, or open it full screen. See how a policy decision is applied at the pull request instead of in a later review.
Safeguard's policies, gates, and guardrails are built for this kind of rule, and fix PRs are off by default with every category on Manual until you opt in. The free scan at gold.safeguard.sh/scan can show your starting backlog.
Quick check
Should the first hire write custom scanners?
Rarely. Routing, grouping, and reporting have more payoff early than new detection.
How do I know a dismissal rule is safe?
Sample its outputs monthly and compare against your own judgment. Keep the alert reopenable.
Sources
- GitHub Docs, Dependabot auto-triage rules
- FIRST, EPSS frequently asked questions
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
