Threat intel for engineers: check your stack, ignore the rest

23.09.20264 min readAtalaia team

Engineering teams are told to "consume threat intelligence". In practice that means a feed of advisories, vendor blog posts and actor reports, most of which have nothing to do with the software they run. The result is either alert fatigue or a feed nobody reads.

Our position is simple. For an engineering team, threat intelligence is useful when it answers one question quickly: is this in our stack, and is it reachable? Everything that does not help answer that can wait or go.

What threat intel means for engineers

A SOC or a dedicated intel team cares about actors, campaigns and indicators. That work is valuable, but it is not what a product team needs from its morning. Engineers need to know when a dependency, base image, build tool or SaaS integration they use has a known problem, and whether to drop what they are doing.

That turns threat intel from a reading exercise into a lookup. The advisory says "package X, versions below Y". The engineering question is "where do we have X below Y?" If answering that takes a day of asking around in chat, the intel arrives too late to matter.

Make the answer a query

The way to make that lookup fast is a current software bill of materials for every service and image, stored somewhere you can search. Generate them in CI with Syft on every build:

# In CI, after building the image
syft registry.example.test/payments-api:1.42.0 \
  -o cyclonedx-json=sbom/payments-api.cdx.json

When an advisory lands, you can check one SBOM in seconds:

# Which version of a named package is in this service?
jq -r '.components[] | select(.name == "xz" or .name == "liblzma")
  | [.name, .version] | @tsv' sbom/payments-api.cdx.json

# Scan an SBOM against current vulnerability data with Grype
grype sbom:sbom/payments-api.cdx.json --only-fixed

And across the whole estate:

# Every service that ships a given package, with versions
for f in sbom/*.cdx.json; do
  jq -r --arg svc "$(basename "$f" .cdx.json)" \
    '.components[] | select(.name == "lodash")
     | [$svc, .version] | @tsv' "$f"
done | sort -u

Pair the SBOM with deployment data, which version of each service is running in which environment, and you can say not only "we have it" but "we have it in production in these three services".

What to act on

Once you can answer the lookup quickly, the filter for action is short:

• Exploited in the wild, and in your SBOMs. Public catalogues of known-exploited vulnerabilities are a good primary signal. A match here is today's work.
• Anything touching your build and release tooling. Compromised CI actions, package registry worms and backdoored build dependencies hit the factory, not just one product. The tj-actions/changed-files compromise (March 2025) and the Shai-Hulud npm worm (September 2025) are examples of this class.
• Reachable from the internet. A vulnerable library in an internal batch job is less urgent than the same library behind a public API. Use your architecture knowledge to rank.
• Your identity and SaaS providers. Incidents at the services that hold your tokens or your source code need a response even when no package is involved: rotate, review audit logs, check for new access.

What to ignore

This is the part people find uncomfortable, but saying no is what keeps the feed useful.

• Actor profiles and campaign names. Interesting reading, rarely actionable for a product team. Leave them to whoever runs detection.
• Generic trend reports. "Attacks on the cloud are rising" does not change what you do this week.
• Advisories for software you do not run. If the SBOM query returns nothing, you are done. Record that you checked and move on.
• Severity scores on their own. A critical score for a code path you never call is lower priority than a medium one on your login page.
• Indicator lists without context. Lists of IPs and hashes belong in detection tooling, not in an engineering channel.

What we would do

1. Generate a CycloneDX SBOM with Syft for every image in CI, keyed to the image digest.
2. Store SBOMs centrally and keep a mapping of which digest runs where.
3. Subscribe one channel to a small set of sources: the advisory database for your package ecosystems, a known-exploited catalogue, and the security notices of your Git host, CI and cloud provider.
4. For each new advisory, run the SBOM query. Post the answer, match or no match, in the thread within the hour.
5. Escalate only matches that are exploited, reachable, or in your build tooling. Everything else becomes a normal dependency update.

Threat intel done this way is less about reading more and more about answering faster. The SBOM is the line's parts list; keep it current and most advisories become a two-minute check.

Where this sits on the line

In the tower (in development):