When a security team runs snyk monitor against a repository, the resulting scan doesn't just capture a dependency tree and a list of CVEs — it also captures how much that project matters to the business. Two CLI flags do this work: --project-tags, which attaches arbitrary key=value labels to a project snapshot, and --project-business-criticality, which assigns a criticality tier (low, medium, high, or critical) to that same snapshot. Neither flag changes what vulnerabilities get found. Both change what happens to that data after the scan finishes — how it's grouped in the Snyk dashboard, how it factors into prioritization, and how it gets routed to the right owners. For teams running Snyk CLI across dozens or hundreds of repositories in CI, these two flags are the difference between a wall of undifferentiated findings and a scan history that already knows which service is customer-facing production infrastructure and which is an internal sandbox.
What do --project-tags and --project-business-criticality actually do?
They attach metadata to the Project object Snyk creates on its platform — not to the vulnerability findings themselves. --project-tags takes one or more comma-separated key=value pairs, for example --project-tags=team=payments,division=platform, and stores them against the project record so it can be filtered or grouped later in the Snyk UI or API. --project-business-criticality takes one of four documented tiers — critical, high, medium, or low — and is typically used alongside two companion attributes: --project-environment (values like frontend, backend, internal, external, mobile, saas, onprem, hosted, distributed) and --project-lifecycle (production, development, sandbox). Snyk documents all four together as "project attributes" — organizational context that sits on top of the raw scan output.
Why do these flags only apply to snyk monitor, not snyk test?
Because snyk test is a stateless, point-in-time scan that never creates a persistent object on Snyk's platform, while snyk monitor uploads a dependency snapshot and creates or updates a Project record that lives in the org indefinitely. snyk test is designed to run in a pull-request gate: it scans the current dependency tree, prints or fails on findings, and exits — there's nothing on the backend to attach a tag to. snyk monitor is designed for continuous tracking: it registers (or refreshes) a project in Snyk's inventory so that newly disclosed CVEs get matched against it going forward, even if nobody re-scans that repository for months. In a typical CI pipeline this splits into two steps — snyk test on every pull request to block merges on new critical issues, and snyk monitor on merge to the default branch (or on a nightly schedule) to keep the persistent snapshot current. The tagging flags belong on that second step, because that's the only command that produces something durable enough to tag.
How does business-criticality change what teams see in Snyk's reporting?
It becomes an input to how issues get ranked, and a first-class filter in Snyk's reporting views and API, rather than a label that just sits in a sidebar. Picture two repositories that both pull in the same vulnerable version of a logging library with an identical CVSS score. One was monitored with --project-business-criticality=critical because it backs a customer-facing payment API; the other was monitored with --project-business-criticality=low because it's an internal documentation mirror. The underlying CVE and CVSS score are identical, but the criticality tag lets a security team filter their backlog to "critical business impact" projects first, or build a report that surfaces the payment API's finding above the documentation mirror's — without anyone having to manually re-triage every duplicate finding across the fleet. This is the core value of the flag: it turns "we have 4,000 open findings" into "we have 4,000 open findings, and here are the 80 on projects we've told Snyk actually matter."
How do project-tags help teams operating at fleet scale?
They let a team slice scan results by whatever organizational dimension actually matters, instead of being stuck with repo names or folder structure as the only grouping mechanism. A security team scanning 300 services in a microservice architecture can't rely on naming conventions to know which repos are in PCI scope, which belong to which engineering team, or which map to a particular cost center — that context usually lives in a spreadsheet, a wiki page, or someone's memory. Setting --project-tags=team=checkout,pci=true,region=eu at monitor time puts that context directly on the Snyk project record, so during a PCI audit the team can filter Snyk's project list to pci=true and get an authoritative list in seconds rather than reconciling a spreadsheet against a repo inventory. Because tags are free-form key=value pairs rather than a fixed enum, organizations can encode whatever taxonomy they already use internally — team ownership, data classification, compliance scope, cost center — without waiting on Snyk to add a new built-in field.
Can these attributes be set or changed after the initial CLI scan?
Yes — both tags and business-criticality are also editable from the Snyk web UI and through the Snyk API on projects that already exist, so the CLI flags are best understood as the fastest way to set them at ingestion time rather than the only way to set them at all. A common pattern is to set sensible defaults in the CI job that runs snyk monitor — for example, tagging every project with the owning team and a lifecycle value pulled from a deployment manifest — and then letting individual project owners refine business-criticality or add additional tags manually through the UI as circumstances change. Because the CLI flags and the UI/API write to the same underlying attribute fields, there's no conflict between the two paths; whichever one runs last wins.
What are the limits of CLI-supplied criticality context?
The main limit is that the entire system depends on someone — a human or a CI config file — supplying an accurate value at scan time, and Snyk has no independent mechanism to verify that a --project-business-criticality=low flag reflects reality. A flag set once in a pipeline YAML file when a service was an internal prototype can easily stay at low long after that service starts handling production customer traffic, because nothing forces a re-evaluation. The same applies to tags: a team= label reflects whoever wrote the CI config on the day it was written, not necessarily who owns the service today. This is a metadata problem common to almost every tool that lets users self-declare importance — the label is only as current as the last person who bothered to update it, and there's no built-in feedback loop that flags a criticality tag as stale.
How Safeguard Helps
Safeguard's software supply chain security platform is built to close exactly this kind of metadata drift, working alongside whatever scanners a team already runs rather than replacing them. Snyk's --project-tags and --project-business-criticality flags are useful precisely because they capture human-supplied business context that a vulnerability scanner can't infer on its own — but that context is only as reliable as the last CI commit that set it. Safeguard ingests scan metadata and SBOM data from tools like Snyk alongside independent signals about how a service is actually deployed — whether it's internet-facing, what data it touches, which pipeline last shipped it to production — and cross-references those signals against the criticality and ownership tags declared upstream. When a project tagged low criticality shows up with an internet-facing endpoint handling customer data, or a tag references a team that no longer owns the repository, Safeguard surfaces that mismatch instead of letting a five-minute-old CI flag silently steer prioritization. The goal isn't to second-guess every tag a team sets — it's to give security teams continuous, corroborated confidence that the business context driving their vulnerability backlog is still true today, not just true on the day someone wrote the pipeline config.