Added instructions how to trigger vuln processing with infra.

[getvictor]

Related issue: Resolves #35239

Documentation changes only for triggering vuln processing. These are useful for on-prem customers and dev/contributor/loadtest environments.

Summary by CodeRabbit

• Documentation
  • Added manual vulnerability processing documentation with step-by-step instructions for Kubernetes and AWS ECS environments, including configuration retrieval and deployment-specific guidance.

[getvictor]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[coderabbitai]

Walkthrough

Adds a new section to the vulnerability processing documentation describing manual triggers for external vulnerability processing when scheduling is disabled. Includes step-by-step instructions for Kubernetes and AWS ECS deployments along with relevant configuration details.

Changes

Cohort / File(s)	Summary
Documentation articles/vulnerability-processing.md	Added manual vulnerability processing section with instructions for triggering vulnerability scans externally in Kubernetes (CronJob-to-Job conversion) and AWS ECS (one-off task execution) environments, including configuration retrieval commands and Terraform integration notes.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~4 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR is documentation-only and does not implement the proposed code fix. While it adds helpful instructions for on-prem customers, it does not address the core requirement of updating the database trigger mechanism.	Clarify whether this PR is solely for documentation or if it requires additional code changes to implement the trigger mechanism update described in issue #35239.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title clearly summarizes the primary change: adding documentation instructions for triggering vulnerability processing in infrastructure deployments.
Description check	✅ Passed	Description provides essential context (related issue, documentation-only scope, target audience) but lacks checklist items from the template such as changes files verification.
Out of Scope Changes check	✅ Passed	All changes are appropriately scoped to documentation additions for vulnerability processing trigger instructions as described in the PR objectives.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch victor/35239-infra-trigger-vuln

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

articles/vulnerability-processing.md (2)

83-83: Use “processing” instead of “scan” to avoid confusion.

This section discusses triggering vulnerability processing (not initiating a new scan). Calling it an “ad‑hoc vulnerability scan” may mislead readers. Consider rephrasing to “ad‑hoc vulnerability processing run.”

---

103-110: Clarify the expected JSON format for --network-configuration.

aws ecs run-task expects a JSON object for --network-configuration. Adding a brief example (or a --query that returns the exact JSON shape from list-targets-by-rule) would reduce copy/paste errors.

Also applies to: 122-124

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR adds documentation for manually triggering vulnerability processing when using external/dedicated vulnerability processing infrastructure. This addresses issue #35239 where fleetctl trigger --name=vulnerabilities is not available when FLEET_VULNERABILITIES_DISABLE_SCHEDULE=true.

Changes:

• Added documentation section "Manually triggering vulnerability processing" to the vulnerability processing article
• Provided instructions for Kubernetes environments using kubectl create job
• Provided instructions for AWS ECS environments using aws ecs run-task

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[getvictor]

@rfairburn Can you check if the infra instructions I added to this guide are accurate?

[rfairburn]

We actually don't use one-off tasks currently for vuln-processing in our terraform but rather a single long-running container that is the only one that can run the vuln-processing and is-not registered to the ALB at all.

This does unfortunately make triggering the vuln scan by fleetctl or by manually running an ECS task impossible as-is.

You can see the permanent service in the external vuln scans here.

Originally we had intended to run the vuln scans as trigger-able by ECS run-task as you describe, but there was some reason that we ended up not doing so -- potentially undesired concurrency or some other reason -- that occured when we were first putting this together ~3 years ago that I cannot recall.

I'm willing to revisit this going forward, but this is the state of things as they stand right now.

It might be possible to scale the service to 0 and then aws ecs run-task but we'd have to override the command in the call as it just does a fleet serve right now. (untested)