If you are trying to fund SAST, DAST, RASP, SCA, WAF, CNAPP, CSPM, CASB or API security for a Virginia or Washington, DC public-sector environment, the strongest starting point is not the product acronym. Start with the risk, the assessed capability gap, the eligible funding or procurement route, the implementation model, and the measurable outcome.
This distinction is especially important in 2026. The federal FY2025 State and Local Cybersecurity Grant Program listing describes FY2025 as the final year of the four-year SLCGP funding cycle, while Virginia's current program page still shows ongoing grant-backed projects and a Phase 2 EDR and vulnerability-management application process. Those facts support continued project activity, but they do not make every AppSec category automatically grant eligible. Official references: FY2025 SLCGP opportunity listing and Virginia VITA Cybersecurity Grants.
The 2026 Funding Reality: Verify the Route Before You Build the Bill of Materials
The official FY2025 federal SLCGP opportunity is archived and states that FY2025 was the final year of the program's four-year funding cycle. The listing shows $91.75 million in FY2025 program funding and says the Governor-designated State Administrative Agency is the only entity eligible to submit the federal application. Source: Simpler.Grants.gov/FEMA FY2025 SLCGP opportunity.
Virginia's own FAQ, last updated February 20, 2026, likewise says four years of SLCGP funding were appropriated from FFY2022 through FFY2025 and that each funding year has a 48-month period of performance. That means grant-supported work may continue after the final appropriation year. It does not mean a new federal FY2026 funding round should be assumed. Source: Virginia VITA SLCGP FAQ.
CISA continues to maintain its SLCGP program resource page, which is useful for federal program background and guidance. Source: CISA State and Local Cybersecurity Grant Program.
Virginia: Build Around VITA and VCPC Priorities, Not Around a Tool Name
Virginia says VITA, working with the Commonwealth's State Administrative Agency, the Virginia Department of Emergency Management, applied for and was approved for all available SLCGP program years. The Virginia Cybersecurity Planning Committee helps determine funding priorities and align investments with closing capability gaps or sustaining capabilities. Source: Virginia VITA Cybersecurity Grants.
The current VITA page lists ongoing cyber-threat indicator information sharing and grant administration projects. It also publishes a Phase 2 application path for EDR and/or Vulnerability Management: complete the assessment form and submit it to the cyber committee. SAST, DAST, RASP, SCA, WAF, CNAPP, CSPM and CASB are not listed there as standalone current project names. That is why an AppSec request should be framed as a capability and risk-reduction scope that fits an approved project area or other valid funding/procurement path. Source: VITA project and Phase 2 application information.
Virginia's SLCGP FAQ describes several execution types, including additional-license purchase, contract-only, implementation, full-service and pass-through funding. It also says application decisions consider subrecipient eligibility, participation in a capability assessment or equivalent assessment, and alignment between the organization's resources and the project execution type. Source: VITA SLCGP execution types and decision criteria.
For the FY2025 SLCGP program year, VITA lists a 40% cost share. It also says the Virginia General Assembly appropriated more than $4.9 million in state cost-share funds in 2022 to minimize or eliminate the need for qualified entities to supply match funds for SLCGP projects. Applicants should verify how any remaining or future project handles match rather than carrying an old assumption into a new request. Source: VITA State Cost Share.
Lead with the capability gap
Example: “The locality lacks repeatable security testing for internet-facing applications and APIs” is a stronger starting point than “we need a DAST license.” Tie the request to an assessment, risk register, audit finding or documented operational gap.
Show who will operate it
Virginia explicitly considers whether the applicant has the knowledge, skills and ability to maintain a solution when selecting an implementation model. Include ownership, staffing, training, integration and lifecycle costs in the scope.
Virginia also publishes statewide information-security policies and standards through VITA, and its Commonwealth IT glossary includes both software composition analysis and static security analysis testing terminology. These are useful references when translating AppSec language into state-governance language. Sources: VITA Policies, Standards & Guidelines and Commonwealth IT Glossary.
Washington, DC: Connect Funding, Budgeting, Acquisition and Security Policy
For DHS preparedness grants, DC's Homeland Security and Emergency Management Agency states that it serves as the State Administrative Agent for the District and National Capital Region. HSEMA applies for grants, acts as the grant point of contact with DHS and FEMA, and administers and manages grant funds for participating District and NCR jurisdictions and agencies. Source: HSEMA Grants Management Support.
For application-security planning, the District's System and Services Acquisition Policy is equally important. The policy was revised March 29, 2024 and applies broadly to District workforce members, contractors, vendors and third parties with access to District information, networks and applications. It requires agencies to determine information-security requirements during mission/business planning, allocate protective resources as part of capital planning and investment control, and establish a discrete information-security line item in programming and budgeting documentation. Source: DC OCTO System and Services Acquisition Policy.
The same policy requires security considerations throughout the system development life cycle and says acquisition contracts must include security functional, strength and assurance requirements explicitly or by reference. This creates a clean proposal pattern: define the security outcome first, then map SAST/DAST/SCA/runtime/cloud controls to contract requirements and acceptance evidence. Source: DC OCTO System and Services Acquisition Policy.
DC's Vulnerability Management Policy, revised February 23, 2023, requires systems and devices connected to the District network to be scanned every quarter; District-owned systems and devices are to receive authenticated scans, and scan results are validated before remediation tickets are generated. That requirement is broader infrastructure vulnerability management, not a definition of DAST. A DAST scope can complement it by focusing on application behavior and exposed application interfaces. Source: DC OCTO Vulnerability Management Policy.
For procurement, the DC Office of Contracting and Procurement provides vendor registration and eSourcing guidance, while the DC Supply Schedule is a multiple-award schedule for commercial products and services. These are procurement mechanisms, not grants, and should be treated as a separate route from grant eligibility. Sources: DC OCP Vendor Registration, Requirements for Doing Business with the District, and DC Supply Schedule.
Virginia similarly uses eVA for public purchasing and business opportunities. A technology that is not directly funded under a specific grant project may still be acquired through an agency's approved budget or procurement path when requirements and funding authority exist. Sources: Virginia eVA search and eVA vendor registration.
SAST, DAST, RASP, SCA, WAF, CNAPP, CSPM and CASB: Map Each Control to a Funding Outcome
NIST's software verification guidance recommends a layered set of techniques that includes static analysis, dynamic analysis, black-box tests, fuzzing and web-application scanning for software with a network interface. NIST's DevSecOps reference model specifically describes SCA and SAST in shift-left development workflows. Those sources are useful for explaining why application-security testing is a program capability rather than a one-time tool purchase. Sources: NIST Recommended Minimum Standard for Verification of Code and NIST NCCoE DevSecOps reference model.
| Control | Primary role | Best proposal evidence | Funding / procurement framing |
|---|---|---|---|
| SAST | Analyze application code without executing it to find security flaws earlier in development. | Repositories covered, scan gates, weakness trends, remediation SLA and developer workflow. | Strong candidate when tied to secure SDLC and measurable risk reduction. |
| DAST | Test a running application or exposed interface from the outside. | Applications/URLs covered, authenticated test scope, findings, retest evidence and release gates. | Useful when the need is application-layer vulnerability testing. |
| SCA | Identify third-party/open-source component risk and support dependency governance. | Dependency inventory, vulnerable component findings, SBOM linkage and remediation ownership. | Useful for software-supply-chain and DevSecOps outcomes. |
| WAF | Filter and enforce controls on HTTP application traffic before it reaches protected applications. | Protected apps/APIs, policy coverage, blocked/monitored events, tuning process and false-positive handling. | Useful when runtime HTTP protection is an identified gap. |
| RASP | Runtime self-protection embedded in or closely coupled to the application/runtime. | Supported runtimes, detected attack conditions, response behavior, performance impact and bypass testing. | Architecture-specific defense in depth; do not present it as a universal mandate. |
| CSPM | Assess cloud configuration and posture against policy, standards and best practices. | Cloud accounts/subscriptions covered, posture findings, policy drift, ownership and remediation workflow. | Useful when cloud misconfiguration and posture are documented risks. |
| CNAPP | Broader cloud-native application protection combining multiple posture, workload and DevSecOps capabilities. | Coverage map across code, cloud resources and workloads; correlated findings; measurable remediation. | A platform category, not a funding category; define the exact capabilities being purchased. |
| CASB | Provide visibility and policy controls for enterprise access to cloud services. | Cloud-service inventory, policy use cases, data/access controls, alerts and integration with identity/SOC workflows. | Best when cloud-service access governance is the documented gap. |
Technical references behind the control map
For WAF, NIST lists Web Application Firewall in its security glossary and OWASP describes a WAF as an application firewall for HTTP applications. Sources: NIST WAF glossary and OWASP Web Application Firewall.
For RASP, OWASP's mobile testing guidance describes runtime application self-protection as embedded runtime security and separately notes that RASP-style resilience is defense in depth rather than a replacement for secure design. Because RASP semantics vary by platform, procurement requirements should name the exact application/runtime behavior required. Sources: OWASP RASP knowledge page and OWASP RASP best-practice guidance.
For CNAPP and CSPM terminology, Microsoft's current Defender for Cloud documentation describes CNAPP as a unified platform category and CSPM as a core capability that assesses and improves cloud-resource security posture. AWS similarly describes Security Hub CSPM as providing a view of cloud security state and assessment against security standards and best practices. These vendor sources explain the product categories; they are not Virginia or DC funding mandates. Sources: Microsoft Defender for Cloud overview and AWS Security Hub CSPM.
For CASB, NIST SP 800-215 includes cloud access security broker among the security technologies considered for modern enterprise networks. Source: NIST SP 800-215.
How to Build a Fundable Application-Security Scope
A strong public-sector funding request connects each cost to a defensible outcome. The following structure works whether the money comes from a grant, an approved cybersecurity budget, a capital project, or a procurement vehicle—while recognizing that the exact eligibility rules differ by route.
1. Baseline the risk
Document affected applications, APIs, cloud resources, data sensitivity, exposure, prior findings and the assessment or policy requirement that established the gap.
2. State the control objective
Use outcome language: prevent vulnerable code from reaching production, reduce exposed attack surface, detect unsafe dependencies, protect HTTP/API traffic, or continuously assess cloud posture.
3. Define coverage
Specify how many applications, repositories, APIs, accounts, subscriptions, workloads or cloud services are in scope and which environments—development, test and production—are covered.
4. Define operations
Name the teams that own triage, remediation, exceptions, tuning, incident escalation, SIEM forwarding, reporting and vendor support after implementation.
5. Define evidence
Commit to measurable outputs such as coverage percentage, recurring scans, high-risk finding age, mean time to remediate, policy drift, blocked runtime attacks and verified retests.
6. Define sustainability
Include licensing, implementation, training, integrations, operations, renewal costs and any staff effort needed after grant or project funding ends.
NIST's software verification guidance supports automated, repeatable testing, including static and dynamic techniques. CISA also treats the Software Bill of Materials as a key building block for software supply-chain risk management. Sources: NIST software verification guidance and CISA Software Bill of Materials.
Example funding justification
Need: Internet-facing citizen services rely on web applications and APIs with inconsistent security testing. Baseline: Assessment identifies gaps in source analysis, dependency visibility, dynamic testing and runtime monitoring. Scope: Cover priority repositories, applications, APIs and cloud workloads; integrate findings with ticketing and SOC workflows. Controls: SAST + SCA in CI/CD, DAST before release, runtime WAF/API monitoring, and CSPM/CNAPP where cloud posture is in scope. Outcome: Increase tested asset coverage, reduce unresolved high-risk findings, verify remediation, and produce auditable operational evidence. Sustainment: Assign owners, training, integration, tuning, renewal and post-project operating costs.
Three Practical Virginia/DC Project Patterns
Citizen-services modernization
A public benefits, licensing, permitting or payment portal may justify SAST and SCA for development pipelines, DAST for pre-release verification, and WAF/API runtime controls for exposed traffic. The funding narrative should connect these controls to the specific applications, APIs and data involved rather than claiming “full AppSec coverage.” NIST's software verification guidance supports static analysis and dynamic web-application testing as distinct verification techniques. Source: NIST Recommended Minimum Standard for Verification of Code.
Cloud-native workload modernization
When an agency is moving applications into cloud accounts, subscriptions, containers or serverless platforms, CSPM or selected CNAPP capabilities can be framed around configuration posture, workload exposure, DevSecOps integration and prioritized remediation. Define which capability is actually needed rather than budgeting for “CNAPP” as an undifferentiated platform. Sources: Microsoft CNAPP/CSPM documentation and AWS CSPM documentation.
Cloud-service governance
When the risk centers on workforce use of SaaS and other cloud services, CASB may be relevant for access visibility and policy enforcement. NIST SP 800-215 places CASB in the context of the modern enterprise network security landscape, alongside technologies such as secure web gateways and zero-trust access. Source: NIST SP 800-215.
What This Means for DevSecOps and SOC Teams: Add API Runtime Evidence
Modern government applications increasingly depend on APIs, so testing coverage should be evaluated alongside runtime visibility. NIST SP 800-228 addresses API risks and protection measures across both pre-runtime and runtime stages, supporting a layered approach rather than treating CI/CD scanning as the complete security program. Source: NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems.
For an API-heavy scope, evaluate whether the architecture can inspect requests and responses, identify sensitive data exposure, surface BOLA/IDOR and business-logic abuse signals, detect suspicious enumeration or replay patterns, and produce SIEM-ready events for incident response and threat hunting. For deeper context, see Ammune's guides on API security testing vs runtime monitoring, BOLA and IDOR API security, API data exfiltration detection, and the API security incident response playbook.
| Evaluation area | Questions to ask | Evidence to request |
|---|---|---|
| Runtime API visibility | Can the team inventory active endpoints and understand normal request/response behavior? | Endpoint inventory, traffic baselines and coverage reports |
| Sensitive data | Can it identify PII, payment data, tokens or secrets in requests and responses? | Data findings, redaction controls and response-leakage examples |
| Authorization abuse | Can it surface BOLA/IDOR, object-level access anomalies and parameter tampering? | Behavioral detections mapped to API context |
| Business logic | Does detection extend beyond signatures and rate limits to suspicious sequences and workflows? | Require proof with realistic application flows |
| SOC integration | Can events be sent to the agency's SIEM with enough context for triage and investigation? | Syslog/API event samples, field mapping and incident workflow |
| Safe enforcement | Can the team begin in monitoring mode, tune policy and move selected controls inline when appropriate? | Deployment modes, tuning plan, rollback and exception process |
For vendor selection, use a proof-of-value approach that measures deployment effort, detection quality, performance, operational ownership and evidence quality rather than counting features. Ammune's API security vendor evaluation checklist and API runtime security platform guide provide related evaluation frameworks.
Common Mistakes That Weaken Government AppSec Funding Requests
Calling every cyber budget a grant
Grant, capital budget, operating budget and procurement vehicles have different authorities and rules. State the route explicitly and cite the current program or procurement source.
Assuming acronyms are eligible costs
A control category such as CNAPP or RASP is not itself an eligibility determination. Map its exact capability to the approved project area, policy requirement and risk outcome.
Confusing vulnerability scanning with DAST
Infrastructure vulnerability management and dynamic application testing can complement each other, but they have different targets, methods and evidence.
Buying without an operating model
Include who tunes, triages, remediates, reports and renews the technology. A funded tool without ownership becomes shelfware and weakens sustainability.
Measuring licenses instead of risk reduction
Coverage, remediation age, verified fixes, protected services, posture improvement and incident workflow are stronger outcomes than seat counts alone.
Leaving API runtime risk out
SAST, SCA and DAST are valuable, but API authorization abuse, business logic and data leakage can require runtime evidence and operational detection.
Virginia & DC Application Security Funding Decision Checklist
- Confirm the live authority. Identify the current grant notice, approved project area, budget authority or procurement vehicle. Do not rely on a prior-year opportunity.
- Confirm applicant eligibility. Distinguish the federal applicant, state administrative agency, subrecipient and vendor roles.
- Trace the need to evidence. Attach or reference the assessment, audit, risk register, vulnerability data or architecture finding that established the gap.
- Choose the right control layer. SAST/SCA for development, DAST for running application testing, WAF/RASP for runtime protection, CSPM/CNAPP for cloud posture/workload scope, and CASB for cloud-service access governance.
- Add API-specific controls where needed. Include runtime API visibility, request/response inspection, sensitive-data detection, BOLA/IDOR and business-logic abuse monitoring when the application depends heavily on APIs.
- Define measurable outcomes. Set baseline and target coverage, finding age, remediation time, posture change, protected workload/application counts, and incident/SIEM workflow evidence.
- Define implementation and sustainment. Include integration, training, tuning, staff ownership, renewals, support and post-award operating costs.
- Validate procurement. If the project is not a direct grant-funded purchase, use the appropriate Virginia eVA or DC OCP route and follow agency-specific acquisition requirements.
- Recheck before submission. Funding conditions and procurement notices change. Verify dates, eligibility, match, period of performance and required documents against the official source immediately before submission.
Primary Official References Used in This Guide
Funding and jurisdiction sources: Virginia VITA Cybersecurity Grants; FY2025 SLCGP opportunity; CISA SLCGP; DC HSEMA Grants Management Support; DC OCTO System and Services Acquisition Policy; DC OCTO Vulnerability Management Policy; DC OCP Vendor Registration; and Virginia eVA.
Technical standards and terminology: NIST software verification guidance; NIST DevSecOps reference model; NIST SP 800-228 API protection; NIST SP 800-215; NIST WAF glossary; CISA SBOM; OWASP RASP guidance; Microsoft CNAPP/CSPM documentation; and AWS CSPM documentation.
Frequently Asked Questions
Are SAST, DAST, RASP, SCA, WAF, CNAPP, CSPM and CASB automatically eligible for Virginia or DC grant funding?
No. Product categories are not automatic eligibility categories. In Virginia, the current VITA cybersecurity-grants page lists specific project areas and decision criteria; applicants should map any requested technology to the approved project area, documented capability gap and current program rules. See the Virginia VITA cybersecurity grants guidance.
Is the federal State and Local Cybersecurity Grant Program open for a new FY2026 application?
Do not assume that it is. The federal FY2025 opportunity is archived and describes FY2025 as the final year of the four-year SLCGP funding cycle. Agencies should verify any new authorization, appropriation or notice before building a 2026 budget around a new federal SLCGP award. See the official FY2025 opportunity listing.
How should a Virginia locality position an application-security project?
Start with the assessed capability gap and the outcome the locality must achieve, then show how the proposed controls support that outcome, how they will be implemented and maintained, and how success will be measured. Virginia's current decision criteria emphasize eligibility, assessment alignment and resources appropriate to the selected execution type. See VITA's current grant guidance.
What role does HSEMA play in Washington, DC cybersecurity grants?
HSEMA states that it serves as the State Administrative Agent for DHS preparedness grant programs awarded to the District and National Capital Region, applies for grants, serves as the DHS/FEMA point of contact, and administers grant funds. See HSEMA Grants Management Support.
Is DAST the same as DC's required vulnerability scanning?
No. DAST is application-focused dynamic security testing, while the DC Vulnerability Management Policy requires quarterly scanning of systems and devices connected to the District network. DAST can complement a vulnerability-management program, but it should not be represented as identical to the policy requirement. See the DC Vulnerability Management Policy and NIST software verification guidance.
What is the practical difference between SAST and SCA?
SAST analyzes source or compiled code for security flaws, while SCA focuses on third-party and open-source components and their known risks. NIST's DevSecOps reference model explicitly includes both SAST and SCA in shift-left analysis. See the NIST NCCoE DevSecOps reference model.
When does a WAF make sense in a government application-security scope?
A WAF is relevant when the scope includes protecting HTTP applications from malicious requests at the application layer. It is strongest when paired with secure development, testing, identity controls and runtime monitoring rather than treated as a substitute for them. See the NIST WAF glossary and OWASP WAF guidance.
Where does RASP fit compared with WAF?
RASP operates inside or closely with the application runtime, while a WAF generally filters HTTP traffic in front of an application. RASP should be treated as defense in depth and validated for the specific application architecture. OWASP's mobile guidance also cautions that RASP-style resilience controls do not replace secure design. See OWASP RASP resilience guidance.
What is the difference between CNAPP and CSPM?
CSPM focuses on assessing and improving cloud security posture, while CNAPP is a broader platform category that can combine posture management with workload and DevSecOps protections. Microsoft documents CSPM as a core CNAPP capability, and AWS documents CSPM as a way to assess cloud environments against security standards and best practices. See Microsoft Defender for Cloud and AWS Security Hub CSPM.
Where can CASB fit in a Virginia or DC security architecture?
CASB can be relevant when the project includes visibility and policy enforcement for access to cloud services. NIST SP 800-215 includes CASB among the technologies considered in a modern secure enterprise network landscape. See NIST SP 800-215.
Should API security runtime monitoring be included with SAST and DAST?
For API-heavy systems, it can be valuable to cover both pre-runtime testing and runtime controls. NIST's API protection guidance addresses risk and controls across pre-runtime and runtime stages, which supports a layered evaluation rather than relying on a single test type. See NIST SP 800-228.
What should be verified before submitting a Virginia or DC application-security funding request?
Verify the current funding notice, applicant and subrecipient eligibility, permitted cost categories, match requirements, project period, procurement rules, security-policy requirements, required assessment evidence, sustainability plan and the exact role of each proposed control. Start with the Virginia VITA grants page or DC HSEMA grants page, depending on jurisdiction.
Turn the AppSec Acronyms Into a Defensible Security Outcome
Whether the project is funded through a grant, agency budget or procurement vehicle, Ammune can help teams evaluate runtime API visibility, deployment architecture, SIEM-ready monitoring and proof-of-value criteria alongside existing SAST, DAST, SCA, WAF and cloud-security controls.