{ "metadata": { "name": "AgileFedTech Knowledge Catalog & AI/RAG Corpus", "version": "1.0.0", "lastUpdated": "2026-11-01", "license": "Public Federal Contractor Technical Guidance", "organization": { "legalName": "Agile Federal Technologies LLC", "dba": "AgileFedTech", "cageCode": "XXXXX", "sbaCertifications": [ "SBA Service-Disabled Veteran-Owned Small Business (SDVOSB VetCert)", "SBA Historically Underutilized Business Zone (HUBZone Certified)", "Small Disadvantaged Business (SDB)" ], "headquarters": "Mayagüez, PR 00680", "website": "https://agilefedtech.com" }, "totalDocuments": 8, "totalTokensEstimated": 9953, "ragSpecifications": { "recommendedChunkSize": 512, "recommendedOverlap": 64, "compatibleEmbeddingModels": [ "text-embedding-3-small", "text-embedding-3-large", "text-embedding-004", "bge-large-en-v1.5" ], "supportedVectorDatabases": [ "Qdrant", "Pinecone", "Milvus", "ChromaDB", "Weaviate", "pgvector" ] }, "canonicalCatalogUrl": "https://agilefedtech.com/knowledge/" }, "taxonomy": { "categories": [ { "id": "all", "label": "All Artifacts", "icon": "fas fa-layer-group" }, { "id": "cybersecurity", "label": "Cybersecurity & Zero Trust", "icon": "fas fa-shield-halved" }, { "id": "cloud-devsecops", "label": "Cloud & DevSecOps", "icon": "fas fa-cloud-arrow-up" }, { "id": "compliance", "label": "Compliance & Governance", "icon": "fas fa-file-shield" }, { "id": "procurement", "label": "Federal Procurement & TAA", "icon": "fas fa-handshake-simple" }, { "id": "edge-ai", "label": "AI & Edge Computing", "icon": "fas fa-microchip" } ], "formats": [ "Architecture Blueprint", "Runbook", "SOP", "Whitepaper" ], "difficultyLevels": [ "Beginner", "Intermediate", "Advanced" ] }, "documents": [ { "id": "KNOW-001", "slug": "zero-trust-cloud-architecture-dod", "canonicalUrl": "https://agilefedtech.com/knowledge/zero-trust-cloud-architecture-dod/", "title": "DoD Zero Trust Architecture: Edge Boundary Enforcement Blueprint", "summary": "Architecture blueprint for implementing DoD Zero Trust boundary controls, micro-segmentation, and ICAM enforcement across multi-cloud defense networks.", "category": { "id": "cybersecurity", "label": "Cybersecurity & Zero Trust", "icon": "fas fa-shield-halved" }, "format": "Architecture Blueprint", "difficulty": "Advanced", "readTime": "14 min read", "lastVerified": "2026-10-24", "author": { "name": "AgileFedTech Systems Architecture Bureau", "role": "Defense Cloud Security Engineering" }, "keywords": [ "Zero Trust", "DoD ZTA", "NIST SP 800-207", "Micro-segmentation", "mTLS", "eBPF", "C4ISR", "ICAM", "Boundary Enforcement" ], "keyOutcomes": [ "Enforces 7 Zero Trust pillars aligning strictly with DoD Zero Trust Strategy 2.0 & Target Level criteria.", "Automates dynamic micro-segmentation using mTLS cryptographic envelopes and eBPF kernel network policies.", "Integrates CAC/PKI and OAuth2/OIDC mutual assertion with continuous user and device risk scoring.", "Establishes unified SIEM/SOAR telemetry ingestion for real-time anomalous lateral movement prevention." ], "estimatedTokens": 1611, "ragPromptChunk": "[CONTEXT: DOD ZERO TRUST ARCHITECTURE / BOUNDARY ENFORCEMENT]\nSYSTEM TARGET: Multi-cloud DoD tactical and enterprise networks (AWS GovCloud IL4/IL5, Azure Government Secret IL6, On-Premises Data Centers).\nCORE DIRECTIVES: DoD CIO Zero Trust Strategy 2.0; NIST SP 800-207; OMB M-22-09.\nARCHITECTURAL PILLARS: User, Device, Network & Environment, Application & Workload, Data, Visibility & Analytics, Automation & Orchestration.\nINGRESS CONTROL: Hardened Software-Defined Perimeter (SDP) terminating at mutual TLS (mTLS) gateways; CAC/PIV certificate mutual authentication + ephemeral JWT issuance.\nDATA PATH: Kernel-level eBPF packet inspection via Cilium mesh; zero unencrypted traffic; strict lateral east-west network policy blocking by default.\nFAILURE MODES: Default-deny on all packet drops; circuit breaker on telemetry drop; zero-trust policy engine (PDP) fail-closed mode.\nVERIFICATION: Automated Chaos Mesh adversarial lateral movement emulation and continuous SCAP compliance scanning.", "fullContentMarkdown": "# DoD Zero Trust Architecture: Edge Boundary Enforcement Blueprint\n\n## 1. Executive Summary & Statutory Authority\nThe transition from legacy castle-and-moat perimeter defense to an uncompromising **Zero Trust Architecture (ZTA)** is mandated by the Department of Defense (DoD) CIO Zero Trust Strategy and Roadmap, Federal Zero Trust Strategy (OMB M-22-09), and NIST SP 800-207. \n\nUnder the \"never trust, always verify\" doctrine, this engineering blueprint defines the reference deployment for DoD Impact Level 4 (IL4), IL5, and IL6 sovereign cloud workloads, ensuring continuous cryptographic verification of identity, device health, and network state prior to granting access to mission data.\n\n---\n\n## 2. Seven-Pillar DoD Alignment Matrix\n\n| ZTA Pillar | Control Mechanism | Implementation Technology | Target Compliance Standard |\n| :--- | :--- | :--- | :--- |\n| **1. User** | Multi-Factor PKI / CAC & PIV | Keycloak SSO + DoD PKI Root CAs | NIST SP 800-63B AAL3 |\n| **2. Device** | Continuous Endpoint Posture Assessment | CrowdStrike Falcon Gov + Microsoft Intune | NIST SP 800-128 |\n| **3. Network & Environment** | Software-Defined Perimeter (SDP) & Micro-segmentation | Cilium eBPF Service Mesh + WireGuard | DoD ZTA Capability 3.1 - 3.4 |\n| **4. Application & Workload** | Immutable Containers & Automated Attestation | DoD Iron Bank Base Images + Cosign | NIST SP 800-190 |\n| **5. Data** | Column/Object-Level AES-256-GCM Encryption | HashiCorp Vault Secrets Engine + AWS KMS HSM | FIPS 140-3 Cryptographic Validation |\n| **6. Visibility & Analytics** | Real-Time SIEM/SOAR Event Streaming | Elastic Cloud Enterprise + Splunk Enterprise Security | OMB M-21-31 Tier EL3 |\n| **7. Automation & Orchestration** | GitOps-driven Security Remediation | ArgoCD + Open Policy Agent (OPA) Gatekeeper | DoD DevSecOps Reference Design |\n\n---\n\n## 3. Reference Topology & Network Boundary Flow\n\n```\n+-----------------------------------------------------------------------------------+\n| UNTRUSTED EXTERNAL WAN / DISA DISN |\n+-----------------------------------------------------------------------------------+\n |\n v\n +-------------------------------+\n | F5 BIG-IP / AWS ALB (TLS 1.3) |\n +-------------------------------+\n | (mTLS Ingress + CAC/PIV Validation)\n v\n +-------------------------------+\n | Envoy Policy Enforcement Point |<---> [ Policy Decision Point ]\n +-------------------------------+ [ (PDP) Open Policy Agent]\n | (Approved Token)\n v\n +---------------------------------------------------------+\n | SECURE KUBERNETES WORKLOAD MESH |\n | |\n | [ Pod A: Capture Service ] |\n | | |\n | | (Cilium eBPF mTLS / SPIFFE ID) |\n | v |\n | [ Pod B: Mission Analytics ] |\n | | |\n | v |\n | [ Encrypted DB: FIPS 140-3 Object Storage ] |\n +---------------------------------------------------------+\n```\n\n---\n\n## 4. Implementation Manifest: Cilium eBPF Strict Default-Deny\n\nTo eliminate unauthorized lateral movement across sovereign workloads, deploy this Kubernetes network policy enforcing cryptographic SPIFFE identity verification and default-deny:\n\n```yaml\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n name: \"enforce-zta-strict-zero-lateral\"\n namespace: \"tactical-workloads\"\nspec:\n endpointSelector:\n matchLabels:\n app: \"mission-telemetry\"\n ingress:\n - fromEndpoints:\n - matchLabels:\n app: \"ingress-gateway\"\n toPorts:\n - ports:\n - port: \"8443\"\n protocol: TCP\n rules:\n http:\n - method: \"POST\"\n path: \"/api/v1/telemetry\"\n authentication:\n mode: \"required\"\n type: \"spire\"\n egress:\n - toEndpoints:\n - matchLabels:\n app: \"fips-vault-backend\"\n toPorts:\n - ports:\n - port: \"8200\"\n protocol: TCP\n```\n\n---\n\n## 5. Deployment Verification Checklist\n\n- [ ] **CAC/PIV Ingress Validation:** Verify that clients without approved DoD Root CA certificate chains are severed at the TCP handshake.\n- [ ] **eBPF Packet Inspection:** Execute `cilium monitor --type drop` to confirm zero non-whitelisted cross-pod packets transit the kernel interface.\n- [ ] **FIPS 140-3 Validation:** Confirm kernel crypto modules (`/proc/sys/crypto/fips_enabled`) return `1`.\n- [ ] **Automated Telemetry Forwarding:** Validate audit logs stream to centralized SIEM in accordance with OMB M-21-31 EL3 requirements within 5 seconds of event generation.\n" }, { "id": "KNOW-002", "slug": "cmmc-2-level-2-compliance-runbook", "canonicalUrl": "https://agilefedtech.com/knowledge/cmmc-2-level-2-compliance-runbook/", "title": "CMMC 2.0 Level 2 Compliance & SPRS Hardening Runbook", "summary": "Step-by-step engineering runbook to assess, remediate, and score NIST SP 800-171 controls to achieve CMMC 2.0 Level 2 certification for defense contractors.", "category": { "id": "compliance", "label": "Compliance & Governance", "icon": "fas fa-file-shield" }, "format": "Runbook", "difficulty": "Advanced", "readTime": "16 min read", "lastVerified": "2026-10-20", "author": { "name": "Defense Cyber Compliance Desk", "role": "CMMC Lead Assessor & Systems Auditor" }, "keywords": [ "CMMC 2.0", "NIST SP 800-171", "SPRS", "CUI Protection", "DFARS 252.204-7012", "FIPS 140-3", "System Security Plan", "POA&M" ], "keyOutcomes": [ "Maps all 110 NIST SP 800-171 Rev 2 controls into actionable engineering remediation playbooks.", "Provides automated mathematical calculation rules for Supplier Performance Risk System (SPRS) scoring (-203 to +110).", "Establishes FIPS 140-3 compliant encryption boundaries for Controlled Unclassified Information (CUI).", "Delivers auditor-tested System Security Plan (SSP) and Plan of Action & Milestones (POA&M) frameworks." ], "estimatedTokens": 1349, "ragPromptChunk": "[CONTEXT: CMMC 2.0 LEVEL 2 HARDENING & SPRS SCORING RUNBOOK]\nFRAMEWORK: Cybersecurity Maturity Model Certification (CMMC) 2.0 Level 2 / NIST SP 800-171 Rev 2 / DFARS 252.204-7012, 7019, 7020.\nOBJECTIVE: Eliminate negative point deductions across 110 controls to achieve a perfect +110 SPRS score for defense primes and subcontractors.\nCORE DOMAINS (14): AC (Access Control), AT (Awareness & Training), AU (Audit & Accountability), CM (Config Mgmt), IA (Identification & Auth), IR (Incident Response), MA (Maintenance), MP (Media Protection), PE (Physical Protection), PS (Personnel Security), RA (Risk Assessment), CA (Security Assessment), SC (System & Comms Protection), SI (System & Info Integrity).\nCRITICAL CONTROLS: 3.5.3 (MFA for all CUI access - local & remote); 3.13.11 (FIPS-validated crypto); 3.1.3 (CUI data flow control); 3.6.1-3 (72-hour DoD DIBNet incident reporting).\nAUDIT ARTIFACTS: System Security Plan (SSP), Incident Response Plan (IRP), Configuration Baseline, FIPS Certificate Numbers, C3PAO evidence binder.", "fullContentMarkdown": "# CMMC 2.0 Level 2 Compliance & SPRS Hardening Runbook\n\n## 1. Regulatory Context & Scope of Applicability\nUnder **DFARS 252.204-7012**, **7019**, and **7020**, any contractor handling **Controlled Unclassified Information (CUI)** or **Covered Defense Information (CDI)** must achieve third-party certification by an authorized **C3PAO** (Certified Third-Party Assessment Organization) prior to contract award.\n\nThe objective of this runbook is to remediate the complete set of 110 controls defined in **NIST SP 800-171 Rev 2**, maximizing your Supplier Performance Risk System (SPRS) score to **+110** and ensuring audit defensibility.\n\n---\n\n## 2. High-Impact Control Domains & Value Weighting\n\n| Domain Code | Family Name | Control Count | Point Value Impact | Primary Failure Vector |\n| :--- | :--- | :--- | :--- | :--- |\n| **AC** | Access Control | 22 | Up to -5 pts each | Missing least privilege / split tunneling enabled |\n| **IA** | Identification & Authentication | 11 | Up to -5 pts each | Lack of MFA for local console logins |\n| **SC** | System & Communications Protection | 16 | Up to -5 pts each | Unapproved non-FIPS cryptographic ciphers |\n| **AU** | Audit & Accountability | 9 | Up to -5 pts each | Inadequate log retention or lack of NTP sync |\n| **IR** | Incident Response | 9 | Up to -5 pts each | Inability to report to DoD DIBNet within 72 hours |\n| **SI** | System & Information Integrity | 7 | Up to -5 pts each | Flawed patch cadence or missing EDR sensor |\n\n---\n\n## 3. Critical Remediation Protocols\n\n### 3.1 Control 3.5.3: Multifactor Authentication (MFA)\nMFA is required for **all** local and network sessions accessing systems that process, store, or transmit CUI. SMS authentication is strictly unacceptable.\n* Enforce FIDO2 WebAuthn hardware tokens (YubiKey 5 FIPS Series) or DoD CAC/PIV credentials.\n* Disable legacy basic authentication across all mail endpoints (POP3, IMAP, SMTP).\n\n### 3.2 Control 3.13.11: FIPS-Validated Cryptography\nAll encryption protecting CUI in transit and at rest must employ cryptographic modules validated by the NIST Cryptographic Module Validation Program (CMVP).\n* **Linux Hosts:** Verify `/proc/sys/crypto/fips_enabled` is set to `1`.\n* **TLS Configuration:** Enforce TLS 1.3 or TLS 1.2 with approved suites: `ECDHE-ECDSA-AES256-GCM-SHA384` or `ECDHE-RSA-AES256-GCM-SHA384`.\n\n```bash\n# Verify OpenSSL FIPS 140-3 provider status on RHEL 9\nopenssl fipsinstall -out /etc/pki/tls/fipsmodule.cnf -module /usr/lib64/ossl-modules/fips.so\nfips-mode-setup --check\n# Expected Output: FIPS mode is enabled.\n```\n\n---\n\n## 4. Automated Audit Evidence Collection Script\n\nExecute this bash auditing script to collect automated evidence of local password policies, audit daemon status, and cryptographic module state:\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\nOUTPUT_DIR=\"/opt/cmmc-evidence-$(date +%Y%m%d)\"\nmkdir -p \"${OUTPUT_DIR}\"\n\necho \"[*] Collecting CMMC 2.0 Evidence...\"\n\n# 1. Audit Daemon Configuration (Control 3.3.1)\nauditctl -l > \"${OUTPUT_DIR}/audit_rules.txt\"\nsystemctl status auditd > \"${OUTPUT_DIR}/auditd_status.txt\"\n\n# 2. FIPS Kernel State (Control 3.13.11)\ncat /proc/sys/crypto/fips_enabled > \"${OUTPUT_DIR}/fips_state.txt\"\n\n# 3. SSH Hardening (Control 3.1.12, 3.13.8)\nsshd -T | grep -E \"(ciphers|macs|kexalgorithms|permitrootlogin)\" > \"${OUTPUT_DIR}/sshd_hardening.txt\"\n\n# 4. User Accounts without Password Expiration (Control 3.5.10)\nawk -F: '($2 == \"\" ) { print $1 \" has no password!\"}' /etc/shadow > \"${OUTPUT_DIR}/empty_passwords.txt\"\n\necho \"[+] Evidence collection complete: ${OUTPUT_DIR}\"\n```\n\n---\n\n## 5. C3PAO Assessment Readiness Checklist\n\n- [ ] **System Security Plan (SSP):** Documented system boundary, CUI flow diagrams, and operational environment descriptions signed by corporate CISO.\n- [ ] **DIBNet Reporting Readiness:** Confirmed active DoD ECA Medium Assurance Certificate for submitting DIBNet incident reports within 72 hours.\n- [ ] **FIPS 140 Validation Numbers:** Documented CMVP certificate numbers for every disk encryption software, VPN gateway, and cloud storage bucket.\n- [ ] **POA&M Resolution:** All high-risk 5-point deficiencies closed; remaining 1-point items scheduled for resolution within 180 days.\n" }, { "id": "KNOW-003", "slug": "fedramp-high-baseline-continuous-monitoring-sop", "canonicalUrl": "https://agilefedtech.com/knowledge/fedramp-high-baseline-continuous-monitoring-sop/", "title": "FedRAMP High Continuous Monitoring & ConMon Automation SOP", "summary": "Standard operating procedure for continuous monitoring (ConMon), automated vulnerability scanning, POA&M management, and annual 3PAO assessments under FedRAMP.", "category": { "id": "compliance", "label": "Compliance & Governance", "icon": "fas fa-file-shield" }, "format": "SOP", "difficulty": "Intermediate", "readTime": "11 min read", "lastVerified": "2026-10-18", "author": { "name": "Cloud Security Operations Bureau", "role": "FedRAMP PMO Liaison & Cloud Security Director" }, "keywords": [ "FedRAMP High", "Continuous Monitoring", "ConMon", "POA&M", "3PAO", "Vulnerability Scanning", "NIST SP 800-53", "ATO" ], "keyOutcomes": [ "Standardizes monthly ConMon reporting deliverables required by the FedRAMP PMO and Authorizing Officials.", "Automates container, operating system, and cloud infrastructure CVE ingestion into standardized POA&M templates.", "Enforces statutory 30-day critical and 90-day high vulnerability remediation SLAs with automated escalation.", "Streamlines annual 3PAO assessment evidence collection to ensure uninterrupted Authority to Operate (ATO)." ], "estimatedTokens": 1047, "ragPromptChunk": "[CONTEXT: FEDRAMP HIGH CONTINUOUS MONITORING (CONMON) SOP]\nAPPLICABLE BASELINE: FedRAMP High (421 NIST SP 800-53 Rev 5 Controls).\nPRIMARY DELIVERABLES: Monthly ConMon Executive Summary, Plan of Action & Milestones (POA&M) spreadsheet, raw authenticated vulnerability scan outputs (OS, Web App, Container, Cloud Infrastructure), Deviation Requests.\nVULNERABILITY REMEDIATION TIMELINES (MANDATORY):\n- Critical (CVSS 9.0-10.0): 30 calendar days from discovery.\n- High (CVSS 7.0-8.9): 30 calendar days from discovery.\n- Moderate (CVSS 4.0-6.9): 90 calendar days from discovery.\n- Low (CVSS 0.1-3.9): 180 calendar days from discovery.\nCONMON CYCLE: Monthly upload to FedRAMP Repository on the exact scheduled due date. Late submissions trigger formal deficiency notices.", "fullContentMarkdown": "# FedRAMP High Continuous Monitoring & ConMon Automation SOP\n\n## 1. Purpose & Scope\nThis Standard Operating Procedure (SOP) defines the operational cadence, tooling, and reporting workflows required to maintain an active **Authority to Operate (ATO)** under the **FedRAMP High Baseline** (NIST SP 800-53 Rev 5). Continuous Monitoring (ConMon) ensures that Authorizing Officials (AOs) maintain continuous visibility into the risk posture of the Cloud Service Offering (CSO).\n\n---\n\n## 2. Monthly ConMon Deliverables Schedule\n\n```\nDay 1 - 5 Day 6 - 15 Day 16 - 22 Day 25\n[ Authenticated ] [ False Positive ] [ POA&M Update ] [ Transmit to ]\n[ Scans Run ]-->[ Validation & ]-->[ & Deviation ]-->[ FedRAMP PMO & ]\n[ All Assets ] [ Remediation ] [ Justification ] [ Authorizing AO]\n```\n\n---\n\n## 3. Vulnerability Remediation SLAs\n\n| Severity Level | CVSS v3.1 Range | FedRAMP Remediation SLA | Mandatory Action |\n| :--- | :--- | :--- | :--- |\n| **Critical** | 9.0 – 10.0 | **30 Calendar Days** | Emergency patch or immediate mitigating network isolation |\n| **High** | 7.0 – 8.9 | **30 Calendar Days** | Sprint priority fix; code branch validation |\n| **Moderate** | 4.0 – 6.9 | **90 Calendar Days** | Scheduled monthly release cycle inclusion |\n| **Low** | 0.1 – 3.9 | **180 Calendar Days** | Backlog hygiene tracking |\n\n---\n\n## 4. Automated POA&M Generation Pipeline\n\nAgileFedTech leverages automated Python ETL scripts to ingest authenticated Tenable/Trivy scanner outputs and map CVEs directly into the official FedRAMP POA&M Microsoft Excel template:\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nFedRAMP Automated POA&M Record Generator\nTransforms raw scanner JSON into FedRAMP PMO Compliant Rows\n\"\"\"\nimport json\nfrom datetime import datetime, timedelta\n\ndef evaluate_cve(cve_entry):\n cvss = float(cve_entry.get(\"cvss_score\", 0.0))\n discovery_date = datetime.strptime(cve_entry[\"discovered\"], \"%Y-%m-%d\")\n \n if cvss >= 7.0:\n sla_days = 30\n severity = \"High\" if cvss < 9.0 else \"Critical\"\n elif cvss >= 4.0:\n sla_days = 90\n severity = \"Moderate\"\n else:\n sla_days = 180\n severity = \"Low\"\n \n scheduled_remediation = discovery_date + timedelta(days=sla_days)\n \n return {\n \"poam_id\": f\"POA-{cve_entry['cve_id']}\",\n \"raw_severity\": severity,\n \"weakness_name\": cve_entry[\"title\"],\n \"weakness_description\": cve_entry[\"summary\"],\n \"scheduled_completion_date\": scheduled_remediation.strftime(\"%Y-%m-%d\"),\n \"status\": \"Ongoing\"\n }\n```\n\n---\n\n## 5. Annual 3PAO Assessment Preparation Checklist\n\n- [ ] **Asset Inventory Reconciliation:** Verify 100% concordance between AWS/Azure active instance inventories and the FedRAMP Integrated Inventory Workbook (IIW).\n- [ ] **Penetration Test Execution:** Complete annual third-party external, internal, and lateral penetration testing adhering strictly to the FedRAMP Penetration Testing Guidance.\n- [ ] **Control Subset Testing:** Complete full testing of all mandated annual core controls with an accredited 3PAO.\n- [ ] **Incident Response Tabletop:** Conduct an annual joint tabletop exercise testing communications with US-CERT and agency customer leads.\n" }, { "id": "KNOW-004", "slug": "kubernetes-iron-bank-hardening-runbook", "canonicalUrl": "https://agilefedtech.com/knowledge/kubernetes-iron-bank-hardening-runbook/", "title": "DoD Platform One & Iron Bank Hardened Container Pipeline", "summary": "Engineering runbook for deploying DoD Platform One hardened container images, OpenSCAP compliance scanning, and cryptographic signing into Kubernetes clusters.", "category": { "id": "cloud-devsecops", "label": "Cloud & DevSecOps", "icon": "fas fa-cloud-arrow-up" }, "format": "Runbook", "difficulty": "Advanced", "readTime": "13 min read", "lastVerified": "2026-10-15", "author": { "name": "DevSecOps & Platform Engineering Bureau", "role": "Platform One Solutions Lead" }, "keywords": [ "Platform One", "Iron Bank", "DoD DevSecOps", "Containers", "Kubernetes", "Cosign", "OpenSCAP", "Admission Control", "Kyverno" ], "keyOutcomes": [ "Automates ingestion of hardened base container images from the DoD Iron Bank (registry1.dso.mil).", "Implements Sigstore Cosign and Kyverno admission controllers to enforce cryptographic signatures in cluster runtimes.", "Enforces rootless container execution, read-only root filesystems, and minimal attack surface geometry.", "Provides GitOps-driven deployment manifests with Falco runtime behavioral anomaly detection." ], "estimatedTokens": 1134, "ragPromptChunk": "[CONTEXT: DOD PLATFORM ONE / IRON BANK HARDENED CONTAINER RUNBOOK]\nREGISTRY SOURCE: registry1.dso.mil (DoD Iron Bank).\nSTANDARDS: DoD Enterprise DevSecOps Reference Design; DISA Container Hardening STIG; NIST SP 800-190.\nSECURITY CONTROLS:\n1. Base Image Verification: All workloads must derive from Iron Bank Universal Base Image (UBI9-minimal) or approved base.\n2. Cryptographic Attestation: Every container image digest must be verified by Sigstore Cosign against DoD Platform One signing keys prior to cluster admission.\n3. Runtime Hardening: Must drop ALL Linux capabilities (drop: [\"ALL\"]), run as non-root user (UID >= 10001), enforce readOnlyRootFilesystem: true, and restrict hostPath mounting.\n4. Continuous Scanning: OpenSCAP and Trivy automated scanning integrated into GitLab CI / GitHub Actions runner.", "fullContentMarkdown": "# DoD Platform One & Iron Bank Hardened Container Pipeline\n\n## 1. Overview & DoD Mandate\nThe Department of Defense **Platform One** initiative provides authorized infrastructure and container blueprints with a Continuous Authority to Operate (cATO). **Iron Bank** (`registry1.dso.mil`) serves as the official DoD repository of hardened, digitally signed containers that have cleared automated static analysis, vulnerability scanning, and DISA STIG container compliance.\n\nThis engineering runbook guides teams in configuring continuous automated ingestion, verification, and cluster-level admission enforcement for mission-critical Kubernetes workloads.\n\n---\n\n## 2. DevSecOps Container Ingestion Lifecycle\n\n```\n[ DoD Iron Bank ] [ GitLab / GitHub CI ] [ Sigstore Cosign ] [ Kyverno Admission ]\nregistry1.dso.mil ---> Authenticated Pull ---> Verify Attestation ---> Cluster Gatekeeper\n(Hardened UBI9) Trivy / Anchore Scan & Digest Match Blocks Unsigned Pods\n```\n\n---\n\n## 3. Kubernetes Kyverno Zero-Trust Admission Policy\n\nDeploy this cluster-level Kyverno policy to reject any image that has not been cryptographically signed with the official corporate/DoD Cosign key:\n\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: \"verify-iron-bank-signatures\"\n annotations:\n policies.kyverno.io/title: \"Verify DoD Image Signatures\"\n policies.kyverno.io/category: \"Supply Chain Security\"\nspec:\n validationFailureAction: Enforce\n webhookTimeoutSeconds: 15\n rules:\n - name: \"verify-signature\"\n match:\n any:\n - resources:\n kinds:\n - Pod\n verifyImages:\n - imageReferences:\n - \"registry.agilefedtech.com/*\"\n - \"registry1.dso.mil/*\"\n attestors:\n - entries:\n - keys:\n publicKeys: |\n -----BEGIN PUBLIC KEY-----\n MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAgileFedTechDefenseDevSecOpsPublicKey...\n -----END PUBLIC KEY-----\n```\n\n---\n\n## 4. Hardened Pod Security Context Baseline\n\nAll container workloads running across sovereign clusters must conform strictly to the restricted pod security standards:\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: \"mission-telemetry-engine\"\n namespace: \"defense-core\"\nspec:\n replicas: 3\n template:\n spec:\n securityContext:\n runAsNonRoot: true\n runAsUser: 10001\n runAsGroup: 10001\n fsGroup: 10001\n seccompProfile:\n type: RuntimeDefault\n containers:\n - name: \"engine\"\n image: \"registry.agilefedtech.com/ironbank/ubi9-minimal:latest\"\n securityContext:\n allowPrivilegeEscalation: false\n readOnlyRootFilesystem: true\n capabilities:\n drop:\n - ALL\n volumeMounts:\n - name: \"tmp-scratch\"\n mountPath: \"/tmp\"\n volumes:\n - name: \"tmp-scratch\"\n emptyDir:\n medium: Memory\n```\n\n---\n\n## 5. Production Pipeline Verification Checklist\n\n- [ ] **Cosign Signature Check:** Execute `cosign verify --key cosign.pub $IMAGE_DIGEST` to ensure zero unsigned layers transit staging.\n- [ ] **CVE Delta Threshold:** Confirm zero Critical or High CVEs with available upstream patches remain in the image manifest.\n- [ ] **Rootless Container Execution:** Inspect runtime logs with `kubectl exec -it -- id` verifying non-zero UID.\n- [ ] **Audit Trail Storage:** Verify that container build SBOMs (Software Bill of Materials) are archived in CycloneDX format for 7 years.\n" }, { "id": "KNOW-005", "slug": "disa-stig-automation-ansible-sop", "canonicalUrl": "https://agilefedtech.com/knowledge/disa-stig-automation-ansible-sop/", "title": "Automated DISA STIG Remediation with Ansible & OpenSCAP", "summary": "Standard operating procedure for orchestrating automated DISA STIG baselining, SCAP compliance verification, and continuous security drift remediation on Linux.", "category": { "id": "cloud-devsecops", "label": "Cloud & DevSecOps", "icon": "fas fa-cloud-arrow-up" }, "format": "SOP", "difficulty": "Intermediate", "readTime": "10 min read", "lastVerified": "2026-10-12", "author": { "name": "Infrastructure Automation Practice", "role": "Senior Site Reliability & Linux Systems Engineer" }, "keywords": [ "DISA STIG", "Ansible", "OpenSCAP", "Red Hat Linux", "Ubuntu", "eMASS", "Compliance as Code", "Drift Remediation" ], "keyOutcomes": [ "Automates 200+ Red Hat & Ubuntu DISA STIG rule evaluations with zero human toil.", "Generates Checklist (CKL) files formatted for eMASS upload and Information System Security Officer (ISSO) sign-off.", "Establishes daily cron-based drift detection and idempotent rollback configurations.", "Reduces production OS hardening turnaround times from 3 weeks to under 45 minutes." ], "estimatedTokens": 1084, "ragPromptChunk": "[CONTEXT: DISA STIG LINUX AUTOMATION VIA ANSIBLE & OPENSCAP]\nAPPLICABLE STIGS: Red Hat Enterprise Linux 8/9 DISA STIG; Canonical Ubuntu 22.04 LTS STIG.\nFRAMEWORK: Compliance as Code utilizing Ansible automation playbooks and OpenSCAP oscap CLI tooling.\nAUTOMATED OUTPUTS:\n1. ARF (Asset Reporting Format) XML file.\n2. DISA STIG Checklist (.ckl) ready for STIG Viewer 3.x and eMASS vulnerability tracking.\n3. HTML human-readable compliance scorecard.\nCRITICAL REMEDIATION CATEGORIES:\n- CAT I: High severity; immediate remote root compromises (e.g. telnet enabled, blank passwords). Must be remediated immediately.\n- CAT II: Medium severity; authorization and boundary bypasses (e.g. auditd rules missing, password complexity).\n- CAT III: Low severity; administrative hygiene (e.g. banner text missing).", "fullContentMarkdown": "# Automated DISA STIG Remediation with Ansible & OpenSCAP\n\n## 1. Scope & Objective\nDefense Information Systems Agency (DISA) **Security Technical Implementation Guides (STIGs)** are the technical standard for securing federal operating systems, networks, and applications. Performing manual STIG audits on dozens or hundreds of virtual machines is unscalable and prone to severe configuration drift.\n\nThis SOP documents the implementation of an automated **Compliance-as-Code** pipeline leveraging Ansible and OpenSCAP to assess, remediate, and generate audit-ready Checklist (`.ckl`) artifacts.\n\n---\n\n## 2. STIG Severity Categories (CAT I, II, III)\n\n| Category | Severity | Failure Impact | Remediation Requirement |\n| :--- | :--- | :--- | :--- |\n| **CAT I** | High (CVSS >= 7.0) | Direct, immediate remote exploitation or unauthorized root takeover | Remediation mandatory prior to system network activation |\n| **CAT II** | Medium (CVSS 4.0 - 6.9) | Weaknesses in access controls, audit retention, or network session isolation | Remediated within 30 days of discovery |\n| **CAT III** | Low (CVSS < 4.0) | Degraded defenses, administrative hygiene, or missing warning banners | Remediated within 90 days or documented in POA&M |\n\n---\n\n## 3. Automated Scanning Execution Protocol\n\nExecute OpenSCAP against the official DISA benchmark using the command line:\n\n```bash\n# Execute authenticated scan generating both HTML report and eMASS ARF XML\noscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --results-arf /var/log/stig/arf-report-$(date +%F).xml --report /var/log/stig/stig-scorecard-$(date +%F).html --cpe /usr/share/xml/scap/ssg/content/ssg-rhel9-cpe-dictionary.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml\n```\n\n---\n\n## 4. Idempotent Ansible Remediation Playbook Snippet\n\nBelow is an enterprise Ansible snippet enforcing CAT I and CAT II access control rules:\n\n```yaml\n---\n- name: \"DISA STIG Automated Hardening - Core OS\"\n hosts: all\n become: yes\n tasks:\n - name: \"V-230230: Enforce DoD Login Warning Banner\"\n ansible.builtin.copy:\n dest: \"/etc/issue\"\n owner: \"root\"\n group: \"root\"\n mode: \"0644\"\n content: |\n You are accessing a U.S. Government (USG) Information System (IS)\n that is provided for USG-authorized use only. By using this IS,\n you consent to continuous monitoring and audio/keystroke logging.\n\n - name: \"V-230300: Disable Core Dumps for Setuid Programs\"\n ansible.posix.sysctl:\n name: \"fs.suid_dumpable\"\n value: \"0\"\n state: \"present\"\n reload: yes\n\n - name: \"V-230350: Ensure Password Encryption Uses SHA512\"\n ansible.builtin.lineinfile:\n path: \"/etc/login.defs\"\n regexp: \"^ENCRYPT_METHOD\"\n line: \"ENCRYPT_METHOD SHA512\"\n state: \"present\"\n```\n\n---\n\n## 5. Operational Verification Checklist\n\n- [ ] **Zero CAT I Findings:** Confirm the post-remediation OpenSCAP scan returns 0 fail results for high-severity rules.\n- [ ] **Idempotency Check:** Re-run the Ansible playbook a second time and ensure changed=0 across all target hosts.\n- [ ] **Auditd Rule Persistence:** Verify `/etc/audit/rules.d/audit.rules` is immutable (`-e 2`) and resists tampering.\n- [ ] **CKL Export:** Generate the `.ckl` file and verify compatibility with DISA STIG Viewer 3.x before uploading to eMASS.\n" }, { "id": "KNOW-006", "slug": "taa-ndaa-surveillance-procurement-whitepaper", "canonicalUrl": "https://agilefedtech.com/knowledge/taa-ndaa-surveillance-procurement-whitepaper/", "title": "TAA & NDAA Section 889 Hardware Supply Chain Provenance", "summary": "Strategic whitepaper on verifying hardware origin, firmware integrity, and vendor compliance for tactical surveillance and video systems across federal bases.", "category": { "id": "procurement", "label": "Federal Procurement & TAA", "icon": "fas fa-handshake-simple" }, "format": "Whitepaper", "difficulty": "Intermediate", "readTime": "12 min read", "lastVerified": "2026-10-10", "author": { "name": "Federal Acquisition & Supply Chain Practice", "role": "Procurement Compliance & Trade Attorney" }, "keywords": [ "TAA Compliance", "NDAA Section 889", "FAR 52.204-24", "FAR 52.225-5", "Supply Chain Risk Management", "SCRM", "Surveillance", "Hardware Provenance" ], "keyOutcomes": [ "Decodes FAR 52.204-24, 52.204-25, and 52.225-5 statutory compliance mandates for physical security systems.", "Establishes a 5-step hardware audit protocol to prevent Section 889 barred vendor contamination.", "Defines designated country manufacturing rules under the Trade Agreements Act (TAA).", "Includes sample vendor representation letters and procurement audit evidence templates." ], "estimatedTokens": 1200, "ragPromptChunk": "[CONTEXT: TAA & NDAA SECTION 889 PHYSICAL SECURITY PROCUREMENT]\nSTATUTES:\n1. Trade Agreements Act (TAA) (19 U.S.C. 2501 et seq.) / FAR 52.225-5.\n2. National Defense Authorization Act (NDAA) for FY 2019, Section 889(a)(1)(A) and (a)(1)(B) / FAR 52.204-24, 25, 26.\nCOVERED TELECOMMUNICATIONS / SURVEILLANCE EQUIPMENT (BARRED ENTITIES):\n- Video surveillance & telecommunications equipment produced by: Huawei Technologies Company, ZTE Corporation, Hytera Communications Corporation, Hangzhou Hikvision Digital Technology Company, Dahua Technology Company (and any subsidiary or affiliate).\nCRITICAL RULE: Federal funds CANNOT be expended to procure, obtain, or use equipment containing chips, SOCs, or firmware from covered entities, regardless of third-party OEM rebranding.\nTAA REQUIREMENT: End product must be substantially transformed in the United States or a TAA Designated Country (e.g. Taiwan, South Korea, Japan, EU nations). China is NOT a designated country.", "fullContentMarkdown": "# TAA & NDAA Section 889 Hardware Supply Chain Provenance\n\n## 1. Executive Summary & Statutory Framework\nThe procurement of electronic surveillance, optical perimeter sensors, and telecommunications infrastructure for federal installations is governed by stringent federal legislation designed to eliminate foreign adversary espionage and sabotage vulnerabilities.\n\nTwo statutory frameworks govern all federal hardware purchases:\n1. **Trade Agreements Act (TAA) (19 U.S.C. § 2501 et seq.):** Mandates that products procured by federal agencies originate from the United States or a recognized \"Designated Country\" (FAR 25.003).\n2. **NDAA Section 889:** Prohibits federal agencies and government contractors from procuring, obtaining, or utilizing telecommunications and video surveillance equipment manufactured by named adversarial vendors (Hikvision, Dahua, Huawei, ZTE, Hytera).\n\n---\n\n## 2. Statutory Comparison Matrix\n\n| Statutory Mandate | FAR Clause Reference | Scope of Enforcement | Penalties for Non-Compliance |\n| :--- | :--- | :--- | :--- |\n| **NDAA Section 889(a)(1)(A)** | FAR 52.204-24 & 25 | Direct procurement or acquisition of covered equipment | Immediate contract termination for default; false claims liability |\n| **NDAA Section 889(a)(1)(B)** | FAR 52.204-24 & 25 | Contractor enterprise-wide usage (even on non-government contracts) | Loss of all federal contracting eligibility |\n| **Trade Agreements Act (TAA)** | FAR 52.225-5 & 6 | Country of origin and \"substantial transformation\" rules | False Claims Act investigation, suspension, and debarment |\n\n---\n\n## 3. Substantial Transformation Test\nUnder federal customs and trade law, a product does not become TAA-compliant simply through superficial assembly or software flashing. To qualify as substantially transformed, the raw components must undergo a transformation that creates a **new and different article of commerce** having a distinctive name, character, or use:\n* **Approved:** Surface Mount Technology (SMT) fabrication of bare circuit boards, custom ASIC programming, and final testing in a designated country (e.g., South Korea, Taiwan, United States).\n* **Unapproved:** Screwing a foreign-manufactured Hikvision camera board into a branded plastic housing in the US (rejected by CBP rulings).\n\n---\n\n## 4. Five-Step Supply Chain Verification Protocol\n\n```\n[ Step 1: BOM Analysis ] --> [ Step 2: Chipset Audit ] --> [ Step 3: Firmware Hash ]\nExamine Bill of Materials for Confirm no HiSilicon SOCs Verify cryptographic\nsub-tier vendor ownership or Dahua microcontrollers signatures & update paths\n |\n v\n[ Step 5: Vendor Rep Letter ] <-- [ Step 4: Physical Disassembly & Port Scan ]\nLegally binding C-level Tear down random unit; verify MAC address OUI\nattestation filed with CO and run local network packet sniffer\n```\n\n---\n\n## 5. Contracting Officer Due Diligence Checklist\n\n- [ ] **Chipset Pedigree:** Verify optical sensor processor is manufactured by Ambarella, Qualcomm, or Sony (avoid HiSilicon/Huawei semiconductor families).\n- [ ] **MAC Address OUI Inspection:** Check the first 3 bytes of the camera MAC address against the IEEE OUI registry to ensure no hidden OEM manufacturing links.\n- [ ] **Signed Representation Form:** Execute and retain the FAR 52.204-24 annual representation in SAM.gov and project contract files.\n- [ ] **No Internet Telemetry:** Confirm camera system firmware does not establish default outbound network connections to foreign cloud servers.\n" }, { "id": "KNOW-007", "slug": "tactical-edge-ai-computer-vision-blueprint", "canonicalUrl": "https://agilefedtech.com/knowledge/tactical-edge-ai-computer-vision-blueprint/", "title": "Tactical Edge AI & Offline Computer Vision Architecture", "summary": "Architecture blueprint for deploying low-latency computer vision models, drone feed analytics, and sensor fusion on ruggedized edge compute in DDIL environments.", "category": { "id": "edge-ai", "label": "AI & Edge Computing", "icon": "fas fa-microchip" }, "format": "Architecture Blueprint", "difficulty": "Advanced", "readTime": "15 min read", "lastVerified": "2026-10-08", "author": { "name": "Defense AI & Robotics Laboratory", "role": "Principal Computer Vision & Autonomous Systems Engineer" }, "keywords": [ "Edge AI", "Computer Vision", "YOLOv10", "TensorRT", "DDIL Environments", "Drone Feeds", "Sensor Fusion", "NVIDIA Jetson", "Zero Trust" ], "keyOutcomes": [ "Enables 100% autonomous computer vision inference in Disconnected, Intermittent, and Low-Bandwidth (DDIL) environments.", "Optimizes state-of-the-art vision models with NVIDIA TensorRT to deliver sub-15ms inference latency on ruggedized hardware.", "Implements AES-256 encrypted local buffer storage with secure opportunistic satellite data reconciliation.", "Engineered for extreme operating conditions with hardware-level thermal watchdogs and dual power redundancies." ], "estimatedTokens": 1520, "ragPromptChunk": "[CONTEXT: TACTICAL EDGE AI & OFFLINE COMPUTER VISION BLUEPRINT]\nOPERATING ENVIRONMENT: Disconnected, Intermittent, and Low-Bandwidth (DDIL) tactical scenarios (border surveillance, maritime interdiction, remote airstrips).\nHARDWARE TARGET: Ruggedized NVIDIA Jetson AGX Orin Industrial (MIL-STD-810H, IP67 enclosure).\nMODEL PIPELINE: Custom YOLOv10 object detection and classification engine quantized to INT8 precision via TensorRT.\nPERFORMANCE TARGET: >= 30 FPS at 4K resolution; sub-15ms inference latency; zero reliance on cloud API round-trips.\nSECURITY PROTOCOL: Hardware Root of Trust via Infineon TPM 2.0; encrypted NVMe flash (LUKS AES-256); opportunistic Store-and-Forward sync over Starlink / tactical UHF.", "fullContentMarkdown": "# Tactical Edge AI & Offline Computer Vision Architecture\n\n## 1. Mission Context & DDIL Requirements\nModern tactical edge operations occur in **Disconnected, Intermittent, and Low-Bandwidth (DDIL)** environments where reliable high-speed satellite or cellular backhaul to central cloud infrastructure is impossible or dangerous due to electronic counter-measures.\n\nThis architecture blueprint specifies the hardware, software, and cryptographic design for deploying real-time Computer Vision (CV) and sensor fusion on ruggedized edge units, delivering autonomous threat detection without emitting detectable radio frequency signatures.\n\n---\n\n## 2. Edge Hardware & Software Architecture Stack\n\n```\n+-----------------------------------------------------------------------------------+\n| MULTISPECTRAL SENSORS (Thermal, EO 4K, LiDAR, AIS) |\n+-----------------------------------------------------------------------------------+\n | (GigE Vision / RTSP over TLS)\n v\n+-----------------------------------------------------------------------------------+\n| HARDENED EDGE COMPUTE (NVIDIA Jetson AGX Orin 64GB) |\n| |\n| +-----------------------+ +-----------------------+ +-----------------+ |\n| | GStreamer Pipeline |--->| TensorRT INT8 Engine |--->| Threat Alert | |\n| | (Hardware Accelerated)| | (YOLOv10 DeepStream) | | Dispatch Engine | |\n| +-----------------------+ +-----------------------+ +-----------------+ |\n| | | |\n| v v |\n| [ Encrypted Local DB ] [ LoRa / UHF Tactical ]|\n| [ (SQLite AES-256) ] [ Short Burst Alert ]|\n+-----------------------------------------------------------------------------------+\n```\n\n---\n\n## 3. Real-Time TensorRT Pipeline Implementation\n\nBelow is a Python snippet demonstrating asynchronous inference on edge hardware with hardware-accelerated zero-copy memory buffers:\n\n```python\nimport cv2\nimport numpy as np\nimport tensorrt as trt\nimport pycuda.driver as cuda\nimport pycuda.autoinit\n\nclass TacticalVisionInference:\n def __init__(self, engine_path=\"models/yolov10_int8.engine\"):\n self.logger = trt.Logger(trt.Logger.WARNING)\n with open(engine_path, \"rb\") as f, trt.Runtime(self.logger) as runtime:\n self.engine = runtime.deserialize_cuda_engine(f.read())\n self.context = self.engine.create_execution_context()\n \n # Allocate pinned host & device buffers\n self.input_shape = self.engine.get_binding_shape(0)\n self.output_shape = self.engine.get_binding_shape(1)\n self.h_input = cuda.pagelocked_empty(trt.volume(self.input_shape), dtype=np.float32)\n self.d_input = cuda.mem_alloc(self.h_input.nbytes)\n self.h_output = cuda.pagelocked_empty(trt.volume(self.output_shape), dtype=np.float32)\n self.d_output = cuda.mem_alloc(self.h_output.nbytes)\n self.stream = cuda.Stream()\n\n def detect_frame(self, frame):\n # Preprocess frame without CPU copy\n resized = cv2.resize(frame, (640, 640)).astype(np.float32) / 255.0\n np.copyto(self.h_input, resized.ravel())\n \n # Asynchronous CUDA memory transfer & inference\n cuda.memcpy_htod_async(self.d_input, self.h_input, self.stream)\n self.context.execute_async_v2(bindings=[int(self.d_input), int(self.d_output)], stream_handle=self.stream.handle)\n cuda.memcpy_dtoh_async(self.h_output, self.d_output, self.stream)\n self.stream.synchronize()\n \n return self.h_output\n```\n\n---\n\n## 4. Store-and-Forward Cryptographic Data Sync\n\n1. **Local Enclave Encryption:** Every video frame triggering a positive classification event is saved to an encrypted NVMe partition using Linux dm-crypt with an ephemeral key bound to the motherboard TPM 2.0.\n2. **Opportunistic Burst Sync:** When an approved tactical data link (e.g. secure satellite burst or low-probability-of-intercept mesh) is established, detection metadata and cryptographically signed hashes are transmitted first, with raw video payloads queued for deferred transfer.\n3. **Zero Tamper Persistence:** Attempted chassis intrusion immediately triggers zeroization of local cryptographic keys via internal capacitor pulse.\n\n---\n\n## 5. Field Operational Checklist\n\n- [ ] **Thermal Stability Stress Test:** Operate unit continuously under 100% GPU saturation at +55°C ambient temperature for 72 hours.\n- [ ] **MIL-STD-810H Vibration:** Validate camera mount and compute module maintain optical alignment under sustained 5G shock testing.\n- [ ] **Zero Cloud Dependency:** Verify unit boots, runs, and outputs audio/tactile alerts with the WAN fiber cable completely severed.\n- [ ] **False Positive Calibration:** Confirm classification threshold achieves >98.5% precision against drone and unauthorized vehicle classes.\n" }, { "id": "KNOW-008", "slug": "federal-sdvosb-hubzone-sole-source-whitepaper", "canonicalUrl": "https://agilefedtech.com/knowledge/federal-sdvosb-hubzone-sole-source-whitepaper/", "title": "Federal Contracting Officer Guide to SDVOSB & HUBZone Sole-Source", "summary": "Executive guide for federal Contracting Officers detailing FAR 19 sole-source authority, non-protestable thresholds, and expedited Small Business procurement.", "category": { "id": "procurement", "label": "Federal Procurement & TAA", "icon": "fas fa-handshake-simple" }, "format": "Whitepaper", "difficulty": "Beginner", "readTime": "9 min read", "lastVerified": "2026-10-05", "author": { "name": "Government Contracts & Capture Directorate", "role": "Senior Federal Capture Manager & Former Contracting Officer" }, "keywords": [ "FAR 19.1406", "FAR 19.1306", "SDVOSB Sole-Source", "HUBZone Direct Award", "Justification & Approval", "SBA VetCert", "Non-Protestable Thresholds" ], "keyOutcomes": [ "Provides authoritative legal references for direct sole-source awards under FAR 19.1406 (SDVOSB) and FAR 19.1306 (HUBZone).", "Outlines statutory non-protestable thresholds up to $4.5M (general) and $5.0M (manufacturing/VA Veterans First).", "Includes step-by-step Justification and Approval (J&A) documentation blueprints to accelerate awards.", "Reduces agency procurement lead time (PALT) from an average of 180 days to under 30 days." ], "estimatedTokens": 1008, "ragPromptChunk": "[CONTEXT: FEDERAL SDVOSB & HUBZONE SOLE-SOURCE PROCUREMENT GUIDE]\nTARGET AUDIENCE: Federal Contracting Officers (COs/KOs), Contracting Officer Representatives (CORs), and Small Business Advocates.\nSTATUTORY AUTHORITIES:\n- SDVOSB Direct Awards: FAR 19.1406 / Veterans Benefits, Health Care, and Information Technology Act of 2006 (Public Law 109-461).\n- HUBZone Direct Awards: FAR 19.1306 / Small Business Reauthorization Act of 1997 (15 U.S.C. 657a).\nTHRESHOLDS FOR DIRECT SOLE-SOURCE WITHOUT COMPETITION:\n- Up to $4.5M for services and non-manufacturing NAICS.\n- Up to $7.0M for manufacturing NAICS codes.\n- No competitive protest rights for disappointed competitors below statutory thresholds provided CO documentation satisfies FAR requirements.\nKEY BENEFITS: Eliminates prolonged RFP cycles; slashes Procurement Administrative Lead Time (PALT) by 60-90%; immediately fulfills mandatory agency socioeconomic small business utilization goals.", "fullContentMarkdown": "# Federal Contracting Officer Guide to SDVOSB & HUBZone Sole-Source\n\n## 1. Executive Summary & Legal Foundation\nFederal acquisition regulations empower Contracting Officers (COs) with specialized statutory authorities to award direct, sole-source contracts to certified small businesses to accelerate mission fulfillment and achieve federal socioeconomic utilization goals.\n\nAs a certified **Service-Disabled Veteran-Owned Small Business (SDVOSB)** through SBA VetCert and a certified **HUBZone** business headquartered in Mayagüez, Puerto Rico, **AgileFedTech LLC** provides federal agencies with two distinct, legally defensible sole-source pathways.\n\n---\n\n## 2. Sole-Source Thresholds & Statutory Authority\n\n| Certification Vehicle | Statutory Authority | Services Threshold | Manufacturing Threshold | Protest Vulnerability |\n| :--- | :--- | :--- | :--- | :--- |\n| **SBA SDVOSB** | FAR 19.1406 | **$4,500,000** | **$7,000,000** | Non-protestable under FAR 19.307 |\n| **SBA HUBZone** | FAR 19.1306 | **$4,500,000** | **$7,000,000** | Non-protestable under FAR 19.306 |\n| **VA Veterans First (Vets First)** | 38 U.S.C. § 8127 | **$5,000,000** | **$5,000,000** | Non-protestable under 38 U.S.C. 8127(c) |\n\n---\n\n## 3. Four-Step Streamlined Sole-Source Workflow\n\n```\n[ Step 1: Identify Need ] --> [ Step 2: Market Research ] --> [ Step 3: J&A Document ] --> [ Step 4: Direct Award ]\nAgency program manager files CO determines one eligible CO drafts short Sole-Source Contract executed in\nstatement of work & budget SDVOSB/HUBZone can satisfy J&A under FAR 13.5 or 19.1406 20-30 days total PALT\n```\n\n---\n\n## 4. Sample Justification & Approval (J&A) Language\n\nContracting Officers can tailor this standard justification language for AgileFedTech sole-source actions:\n\n> \"Pursuant to FAR 19.1406(a), the Contracting Officer may award a sole-source contract to an SDVOSB concern if only one SDVOSB is reasonably expected to perform at a fair and reasonable price, and the anticipated award price does not exceed $4,500,000. AgileFedTech LLC (CAGE: XXXXX, SAM UEI: XXXXXXXX) maintains verified SBA VetCert accreditation and possesses unique cleared personnel capabilities required for immediate project execution, preventing unacceptable program delays.\"\n\n---\n\n## 5. Contracting Officer Benefits Summary\n\n* **Dramatic PALT Reduction:** Decreases procurement lead times from 6 to 9 months down to 20 to 30 days.\n* **Dual Socioeconomic Scorecard Impact:** Direct awards satisfy both the 3% (increasing to 5%) statutory SDVOSB agency goal and the 3% HUBZone prime contracting mandate.\n* **Competitive Evaluation Protection:** Under FAR 19.1406, awards made pursuant to these authorities are not subject to standard bid protest procedures by other commercial contractors.\n* **Price Reasonableness:** Pricing can be validated swiftly using GSA schedule rates or historical government acquisition pricing.\n" } ] }