AI
Managing Vulnerabilities Across 15 Scanners
Slack runs 15+ security scanners covering SAST, DAST, container scanning, infra scanning, and third-party package analysis. Some scanners push results to Jira automatically. Others, like bug bounty and vendor reports, need manual triage per finding: false positive evaluation, ownership lookup, severity assignment, and ticket creation. All that logic lives in separate codebases, one per scanner. Without deduplication, developers get duplicate tickets. Without auto-closing, they can’t confirm a fix worked without asking a security engineer.
Why Commercial Tools Failed the Evaluation
Slack evaluated 15 to 16 commercial vulnerability management solutions and ran detailed POCs on three. None met all requirements. No evaluated vendor was FedRAMP High compliant. Some weren’t even FedRAMP Moderate, and some hosted their solution on their own infrastructure, which added cost to onboard. Connectors for Slack’s in-house scanners were missing. Jira templates were too rigid. Several vendors were early-stage startups near acquisition. During the POC, the team effectively beta-tested buggy products. Building in-house won.
The Four-Model Data Schema
The aggregator organizes data into four entities. A finding rule defines the vulnerability class, such as a CVE or an S3 misconfiguration, and may carry a reference like a NIST database link or a Nessus plugin ID. A finding is one detected instance, with discovery date, description, due date, and environment-adjusted severity. A prod asset and a dev asset with the same CVE get different severity scores. An asset captures what was affected: a Docker image, repo, or host. A finding group ties related findings into one Jira ticket.
Flexible Grouping for Every Scanner
Different scanners need different grouping logic. A third-party package scanner groups by package name: all CVEs under one package have one fix, which is upgrading the package. A SAST tool groups by vulnerability category, collecting all XSS instances in one ticket. The aggregator supports custom fields, so a tool like Wiz can add a “wiz_environment” field and group by it. Grouping factors carry a priority number. When a higher-priority field is missing, the system falls back to the next level rather than failing.
Deduplication, Auto-closing, and Jira Updates
When a scanner pushes a new finding for an asset that already has an open ticket, the aggregator appends it as a Jira subtask. No new ticket is created. When a vulnerability disappears from the next scan, the aggregator marks it resolved and closes the ticket. Engineers never log into Jira to close items themselves. Ownership assignment works through Slack’s internal Omni service: one API call maps a service name to the team that owns it. The aggregator pulls that data and routes the ticket.
Q&A
How do per-finding SLAs work when multiple findings share one ticket? Each subtask carries its own SLA, and the grouping system can separate findings by severity to avoid mixed-SLA tickets entirely. ▶ Watch (28:36)
Does the aggregator use CVSS scores? Mostly yes, with environmental adjustments for exploitability, proof-of-concept availability, and whether the vulnerable code path is actually reachable. ▶ Watch (29:23)
How do you handle the same CVE reported by two scanners at different severities? Cross-tool deduplication is still in development; the current strategy prefers the CVE record from whichever tool has historically produced more reliable results. ▶ Watch (31:32)
How does grouping work when one team owns multiple container images? A custom field captures the container name or tag, and all matching images group under one ticket assigned to the owning team. ▶ Watch (36:50)
Notable Quotes
all of these scanners are kind of like siloed Atul Gaikwad · ▶ Watch (10:06)
a lot of this logic is kind of a duplicate Atul Gaikwad · ▶ Watch (10:19)
nothing really super special going on Nicholas Lin · ▶ Watch (17:13)
Key Takeaways
- Centralizing 15+ scanner outputs into one PostgreSQL-backed store eliminated duplicate-finding and missed-autoclose problems
- Grouping logic is configurable per scanner, with priority-ordered fallbacks to handle incomplete or malformed field data
- Ownership assignment via the Omni service API removes manual triage from the deduplication and ticket-routing workflow
About the Speaker(s)
Atul Gaikwad has 15+ years of experience in application and cloud security, DevSecOps, and third-party risk management. He works as a Staff Product Security Engineer at Salesforce, focused on security automation that reduces manual burden on developers. He started his career as a penetration tester before shifting to building security tooling.
Nicholas Lin graduated from the University of Virginia and joined Slack’s Product Security team as a Software Engineer. Over two years he built automation systems that help risk owners remediate security issues at scale.