Procurement: Security Tooling
What this is and who it’s for
This runbook tells you how to buy security tooling — application scanning, dependency and secrets scanning, container scanning, vulnerability management, and security log analytics — on a Maryland contract vehicle without buying shelfware or getting locked in. It’s for an agency tech lead who needs the capability, the procurement officer who has to put it on a contract, and the security officer or ISSO who has to defend the authorization. It assumes you already know your security baseline; the job here is converting that baseline into a defensible requirement, the right vehicle, a SOW you can stand behind, and an evaluation that picks a tool on merit. If you can’t yet name the controls you’re trying to satisfy and the findings you intend to act on, stop and read the prerequisites first.
Prerequisites
- You’ve read the Security Baselines technical-practice runbook and can name the controls and the risk categories you need coverage for. You cannot write a defensible requirement for a capability you can’t map to a baseline.
- Your agency has decided who triages findings and on what cadence [VERIFY]. A scanner with no triage owner produces noise, not security — settle ownership before you price anything.
- Your agency has determined its compliance posture for hosted services — whether FedRAMP or StateRAMP authorization is required, and at what impact level [VERIFY]. This narrows the vendor field before you start, so settle it up front.
- You know which control framework your authorization runs against — typically NIST 800-53 for an ATO [VERIFY] — and what evidence your assessors expect a tool to produce. Tools that can’t emit ATO evidence cost you twice: once to buy, again to satisfy assessors by hand.
The practice
Run this as four moves in order: define the requirement by category, pick a vehicle, write the SOW, evaluate. Authorization and triage capacity are the hinge decisions — they change the vehicle, the SOW, and whether the tool is usable at all — so make them explicitly rather than letting a vendor make them for you.
Define the requirement by category
Write down what you need per category before you talk to anyone: the coverage, the integration points, who triages, and the compliance posture. State coverage as outcomes (“block merges on critical CVEs in direct dependencies,” “fail the pipeline on hardcoded secrets”), not product features. Decide where each tool runs — in the pipeline, on a registry, against a running target — because that drives integration scope. Capture triage capacity honestly, since a tool that produces more findings than your team can action becomes shelfware.
Map the capability to a tool category
SAST / DAST application scanning
Static analysis (SAST) reads source to find vulnerable code patterns before runtime; dynamic analysis (DAST) probes a running application from the outside. Together they cover code-level and runtime application risk that dependency scanning misses. Procurement angle: the deciding terms are CI/CD integration depth and false-positive rate at your codebase size — require a proof-of-value scan against your real repositories, not a vendor sample, and put the false-positive triage support in the SOW.
SCA / dependency and secrets scanning
Software composition analysis (SCA) inventories third-party dependencies and flags known CVEs; secrets scanning catches credentials committed to source. This is usually the highest-yield, lowest-cost category and the first one most agencies buy. Procurement angle: many capable options are open source or bundled into a source-control platform you already license, so confirm what your existing platform [VERIFY] already covers before buying a standalone tool.
Container / image scanning
Scans container images and their layers for vulnerable OS packages and misconfigurations, ideally in the registry and the pipeline before deploy. Essential if your workloads run in containers; irrelevant if they don’t. Procurement angle: this capability is frequently native to the cloud provider or registry you already pay for, so price the standalone tool against the marginal cost of turning on what you have [VERIFY].
Vulnerability management platform
Aggregates findings from the scanners above into one prioritized, trackable backlog with ownership, SLAs, and remediation workflow. This is the layer that turns scanner output into action and is what prevents shelfware. Procurement angle: the deciding terms are how many finding sources it ingests and whether it exports ATO evidence in your assessors’ format [VERIFY NIST 800-53] — buy the workflow, not another scanner.
SIEM / log-security analytics
Collects and correlates security-relevant logs to detect and investigate threats, and overlaps heavily with observability tooling. If you’re also standing up logging for operations, coordinate so you don’t buy two log pipelines — see Procurement: Observability Tooling. Procurement angle: scope and authorization dominate, since this tool ingests your most sensitive logs; require the authorization as a gate and decide retention before pricing, because retention drives the SIEM bill the way it drives observability cost.
Choose a delivery model
Commercial SaaS suite
The vendor runs an integrated suite covering several categories; you send data and pay by asset, scan, or seat. Fastest to stand up and lowest operational burden, but it sends agency source, artifacts, or logs to a third party — so the vendor must carry the required FedRAMP/StateRAMP authorization [VERIFY], and that requirement belongs in the SOW as a pass/fail gate. Procurement-wise this is a service subscription, which often maps cleanly to an existing IT-services or software vehicle. Watch the cost shape: per-asset and per-scan pricing scales with your footprint, not your budget.
Open-source assembled stack
You assemble and run open-source scanners on your own infrastructure. No license cost and full data control, which simplifies the compliance story because source and artifacts never leave your boundary. The cost moves from license to labor, so the procurement is usually for implementation and managed-operations services plus compute — not for the software itself. Budget for the people who will run it and triage it; “free software” is not free to operate, and an unstaffed open-source stack is shelfware with extra steps.
Cloud-provider-native security services
You use the security tooling built into the cloud provider your workloads already run on. Tight integration and one less vendor relationship, and it typically inherits the provider’s existing authorization [VERIFY], which can shorten the compliance review. The trade is coverage and portability: native tools may not span every category, and they’re provider-specific, so the data-exit clause matters more here, not less. Procurement often rides the existing cloud-services vehicle as an add-on rather than a new contract.
Map to a vehicle
Match the model to the smallest vehicle that fits. A single-category SaaS subscription under the small-purchase threshold [VERIFY] may not need a full RFP; a multi-year enterprise suite will. Open-source implementation work is a services buy and may fit a master services vehicle. Confirm the candidate vehicles in Procurement notes before committing.
Write the SOW
Fork the skeleton in Reference implementation. Keep coverage, integration points, triage support, and compliance posture as explicit, testable requirements — not preferences. Put data ownership, exit, and the ATO-evidence output in writing every time, regardless of model.
Evaluate
Score against the published rubric, not against the demo. Weight compliance authorization and data ownership/exit as gates: a tool that fails either is out, however good the dashboards look. Run a proof-of-value against your real assets and evaluate the false-positive rate and triage burden at your scale, not at the vendor’s curated scale.
Reference implementation
Fork this SOW skeleton. Every bracketed item is a decision you must make or a value a human must verify; do not ship it with placeholders intact.
# STATEMENT OF WORK — SECURITY TOOLING
### 1. Scope
The Contractor shall provide [commercial SaaS suite | implementation and managed operations of an open-source stack | cloud-native add-on] covering [SAST/DAST | SCA/secrets | container scanning | vulnerability management | SIEM] for [AGENCY / SYSTEM]. Estimated footprint: [N repositories], [N applications], [N container images], [N assets/hosts]. Term: [base period + option years].
### 2. Required Coverage
The tooling shall, for each in-scope category:
- Detect and report [vulnerability classes] against [target type].- Run within the agency CI/CD pipeline and on [registry / running target].- Gate [merges / builds / deploys] on [severity threshold] findings.- Produce findings with severity, location, and remediation guidance.
### 3. CI/CD Integration
The tooling shall integrate with [AGENCY pipeline — e.g. GitHub Actions] as a pipeline step, fail builds on [policy], and post results to [code review / ticketing]. Integration shall not require agents that violate agency endpoint policy.
### 4. Triage and False-Positive Support
The Contractor shall support finding triage: suppression of accepted risks, baseline of pre-existing findings, and a measured false-positive rate of [target] against agency code in a proof-of-value before award.
### 5. Compliance Authorization and ATO Evidence
Any service receiving agency source, artifacts, or logs shall hold [FedRAMP | StateRAMP authorization at IMPACT LEVEL] for the term. The tooling shall export evidence mapped to [NIST 800-53 controls] in a format the agency assessor accepts for ATO and continuous monitoring.
### 6. Data Ownership and Exit
All scan data, findings, and configuration are the property of [AGENCY]. On termination the Contractor shall, within [N days], export all data in [open format] at no additional charge and certify deletion of agency data from its systems. No proprietary format shall prevent export of findings.
### 7. Support and Onboarding
The Contractor shall provide implementation, pipeline integration, policy and severity-gate configuration, triage workflow setup, and knowledge transfer sufficient for [AGENCY] staff to operate the tooling unaided by end of [period].
### 8. Service Levels
- **Service availability:** [e.g. 99.9%] measured monthly.- **Vulnerability feed currency:** new CVEs reflected within [target].- **Support response:** [severity tiers and response times].
### 9. Pricing
Pricing shall be stated at the estimated footprint in Section 1 AND at [+50% | +100%] of that footprint, so cost growth is visible before award. Per-scan, per-asset, and per-seat components shall be itemized. [FILL IN: ceiling / NTE amount per agency budget authority.]Score every responsive bid against this rubric. Treat the two gate rows as pass/fail: a failure on either eliminates the bid regardless of total score.
| Criterion | Weight | Notes |
|---|---|---|
| Compliance authorization (gate) | Pass/fail | FedRAMP/StateRAMP at required level [VERIFY] |
| Data ownership and exit (gate) | Pass/fail | Open-format export, no lock-in |
| Coverage at projected footprint | 25% | Scored against real assets, not vendor sample |
| ATO evidence output | 20% | Maps to NIST 800-53, assessor-acceptable [VERIFY] |
| False-positive / triage burden | 15% | Measured in proof-of-value, not claimed |
| CI/CD integration fit | 15% | Works with current pipeline and policy |
| Cost at projected footprint | 15% | Scored at +50%/+100%, per-asset itemized |
| Support and onboarding | 10% | Response SLAs, knowledge transfer |
Common pitfalls
- You bought a scanner with no plan to triage findings. A tool that emits thousands of findings no one actions is shelfware that also generates audit risk. Assign a triage owner and cadence before award, as in SOW Section 4, and weight triage burden in the rubric.
- Per-scan or per-asset pricing exploded. Pricing looks cheap on a pilot repository and ruinous across the whole estate. Require pricing at +50%/+100% of projected footprint and itemized per-asset/per-scan components before award, as in SOW Section 9.
- Two teams bought overlapping tools. Independent purchases of SCA, container scanning, and SIEM produce redundant licenses and conflicting findings. Inventory what’s already licensed — including capabilities native to your source-control platform and cloud provider [VERIFY] — before buying standalone.
- The tool produces no ATO evidence. If findings can’t be exported in a form your assessors accept, your team rebuilds the evidence by hand at every continuous-monitoring cycle. Make ATO-evidence output a scored criterion and a SOW requirement, per Sections 5 and the rubric.
- You ignored the authorization boundary. Sending source, artifacts, or logs to a SaaS tool that lacks the required FedRAMP/StateRAMP authorization [VERIFY] is a finding waiting to happen. Make authorization a pass/fail gate in evaluation, not a scored line item.
- The “free” open-source tool’s real cost is the ops burden. Zero license cost hides the staffing to run, tune, and triage the stack. Price the people in the SOW as implementation and managed-operations services, or the savings evaporate into unbudgeted labor.
Procurement notes
Candidate Maryland vehicles depend on the delivery model and dollar value, and must be confirmed with your procurement officer.
- Commercial SaaS suite or single-category subscription: [FILL IN: Maryland contract vehicle — e.g. COMMBUYS master contract # / NASPO ValuePoint vehicle].
- Open-source implementation and managed-operations services: [FILL IN: Maryland IT master services vehicle #].
- Cloud-provider-native security services: amend the existing cloud-services contract [FILL IN: vehicle / order #].
Thresholds decide the path. Below the small-purchase threshold [VERIFY] you may avoid a full solicitation; above it you run an RFP against this runbook’s SOW and rubric [VERIFY]. A typical timeline runs roughly [VERIFY: e.g. 4–8 weeks for a small purchase, 3–6 months for a competitive RFP] — confirm against current Maryland procurement guidance before you commit a date to anyone.
For SOW drafting mechanics beyond this skeleton, see How to write a good SOW.
Maintenance
Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31