Managing security vulnerabilities as a DevSecOps Engineer

Imagine you're a Security Operations Engineer. A critical vulnerability in curl has just been announced. Your compliance policy gives you 30 days to patch 11 different images, owned by 8 different people across multiple teams.

Any service with curl installed now needs to be reviewed. Owners must check whether their service is exposed. And if they're using vulnerable functionality—say, a curl protocol that’s still awaiting a patch—they may need to refactor parts of the codebase, which requires intimate knowledge of the service. You need the right people making the changes. A random engineer unfamiliar with the code won't be able to safely implement the fix. Meanwhile, the patch timeline is unclear.

Now imagine that tomorrow, a new libxml vulnerability is disclosed. It affects a different set of services and teams—so you can’t even bundle these fixes together. And these security issues don’t exactly take vacations.

This is the reality of my work as a Security Ops Engineer—one of the hats I wear at Faros AI. Over time, I’ve learned that managing these cascading vulnerabilities at scale requires access to structured, reliable data.

With the solution I've put in place, we've seen huge benefits: Faster time-to-assignment (from days to minutes!), faster patch cycles, and fewer overdue vulnerabilities. In the sections that follow, I’ll walk through the kinds of data and systems that make this possible.

Challenges with security vulnerability management

Beyond the general chaos of managing vulnerabilities, there are a few specific recurring challenges we face:

• How do we assign vulnerabilities to the right engineers?
  
• How can we reduce the noise for those engineers, so they only get alerts that matter?
  
• When can we automate the resolution of a vulnerability task entirely?
  

Assigning vulnerabilities to the right owner

One of the foundational needs is a reliable, dynamic data source that maps engineers to the services they own. Without this, our team ends up manually maintaining outdated spreadsheets—a process that quickly breaks down as teams reorganize and services multiply.

Preferably, this ownership data would be maintained either by the teams themselves or automatically through a source of truth tied to org structure (like GitHub teams, internal directories, or service catalogs).

To illustrate, imagine you have 100 services. Vulnerabilities will be discovered in them at random times. The engineers closest to each service are best equipped to assess and fix those issues. That means they are also the ones who should manage and update ownership mappings. And critically, they should have access to this data as well.

(Incidentally, this mapping isn’t just useful for vulnerability management—it’s valuable for bug triage, service cataloging, and many other coordination workflows.)

Minimizing noise

Once vulnerabilities are assigned, the next challenge is minimizing noise. As an engineer responsible for a service, I don’t want to receive repeated reminders—daily or even weekly—about a vulnerability that isn’t due for another month. Ideally, I’d get a single task with one or two well-timed reminders as the deadline approaches.

To avoid sending redundant notifications, the Security Ops team needs a way to track which vulnerabilities have already been assigned and to whom. In theory, we could query the task management system (TMS, like Jira or Azure DevOps) for this information. But in practice, most TMS tools aren’t built to handle the shape or volume of vulnerability data. For instance, a single container image might have hundreds of associated vulnerabilities—too many to represent cleanly in one task, depending on the system’s schema and constraints.

Instead, we need a purpose-built system to store this “vulnerability-to-task” memory. One option is to create custom database tables that associate each vulnerability with metadata: the affected image, owning team or engineer, git repository, and corresponding task. But managing this ourselves—designing schemas, maintaining the DB, handling backups—quickly becomes operational overhead. It also risks isolating vulnerability data from other useful engineering ops data.

Automatically resolving outdated tasks

Just as important as assigning tasks is knowing when to close them. If a vulnerable image is no longer in production, we should be able to automatically resolve any open tasks tied to it.

To do this, we need to answer a simple question for each task: Has the service deployed a new image where the vulnerability no longer exists? Answering that requires access to up-to-date image deployment data across all environments, along with their associated vulnerabilities.

As you can imagine, the data requirements here span multiple systems: CI/CD pipelines, image registries, environment metadata, task trackers, and more. Automating this end-to-end requires pulling from all of them—each with its own API or integration model.

Fortunately, at Faros AI, this is where our platform shines. By centralizing all this data and exposing it through a unified GraphQL API, we can build automations that are both flexible and low-maintenance.

How I’m effectively managing security vulnerabilities with Faros AI

To solve the challenges outlined above, I realized I needed reliable access to five key data types:

• Vulnerabilities per image ID – Which CVEs are present on which container images or code repositories, and when they were discovered.
  
• Deployment history – What images are currently running in production, when they were deployed, and their historical lineage for validation.
  
• Compliance rules – When each vulnerability is due, based on internal policies.
  
• Task management system (TMS) IDs – To connect service owners to our Jira for task creation and tracking.
  
• Service ownership – Which engineers or teams are responsible for which services, images, or repos.
  

Happily, I found that most of this data already existed in Faros AI.

Aggregating the data

Here’s how we brought it all together:

• Vulnerability data: We sync CVE data into Faros AI from Vanta, our compliance platform, via an Airbyte connector. Vanta pulls from both our container and code repositories and includes our compliance policies to assign due dates to each vulnerability.
  
• Deployment data: We instrument Faros AI CI/CD events to track builds and deployments per image, per service, per environment—giving us detailed deployment history.
  
• Org + TMS mapping: We link our org chart to Jira users. For each engineer, we have their team(s), Jira user ID, and Jira team ID. This allows us to easily create or update Jira tasks via its API.
  

Adding ownership data

The only missing piece was ownership mapping. I solved this by tagging employees in Faros AI with key-value pairs that indicate which services they own. I generated these tags using a simple script that converted a team-to-service mapping into GraphQL mutations. This data could also come from systems like PagerDuty or be updated via an automated sync.

Importantly, I didn’t need to build a new service, stand up a database, or maintain spreadsheets. Faros AI natively supports all of this and encourages a centralized, connected approach to engineering data.

Automating the workflow

Once the data was in place, I wrote a script that now runs daily—and all with just three access tokens: Faros AI, Jira, and Slack. This is what it does:

A new era of security vulnerability management

This new approach to security vulnerability management has delivered immediate, measurable improvements. We've reduced time-to-assignment for new vulnerabilities from days to minutes. Engineers now receive no more than one Jira task per service per week—a significant decrease from the flood of redundant alerts they previously endured. Most importantly, we're seeing faster patch cycles and a notable reduction in overdue vulnerabilities, even as our infrastructure continues to grow.

As Sara Asher, our Head of Product, Platform puts it:

"This new orchestration of security vulnerabilities has been a game-changer for our teams. By automatically and fairly distributing vulnerability workload based on service ownership in Faros AI, we've reclaimed valuable time while ensuring everyone contributes equitably. It's also made it significantly easier for us to tackle our security backlog effectively."

Ultimately, this isn't just about managing security vulnerabilities—it's about empowering DevSecOps Engineers to take ownership of security in a way that scales. And with the right data in the right place, it’s finally possible.

Curious how Faros AI could help in your environment? Contact us today to learn more.