AFLCMC_Solicitation_SBOM_Vuln_Scanning_SOW_RFI.pdf

DEPARTMENT OF THE AIR FORCE

AIR FORCE LIFE CYCLE MANAGEMENT CENTER (AFLCMC-HNCX)

DRAFT STATEMENT OF WORK (SOW)

Software Bill of Materials (SBOM)

Generation & Vulnerability Analysis Solution

FA8307-26-R-B019

This Statement of Work establishes requirements for an enterprise Software Bill of Materials (SBOM) generation, container analysis, and vulnerability scanning capability to support DevSecOps and Platform One operations. This document is structured for open competition and acquisition through applicable DoD/AFLCMC contracting pathways in accordance with FAR, DFARS, and AFLCMC policies.

1. Purpose Solicit qualified commercial vendors to provide an enterprise solution capable of automated SBOM creation, container image analysis, vulnerability detection, and integration into Air Force DevSecOps pipelines.

2. Scope The contractor shall provide licenses, software, technical support, implementation assistance, and sustainment services necessary to deliver a production-ready solution across classified and unclassified cloud environments (IL4/IL5/IL6 as applicable).

3. Applicable Guidance

• FAR/DFARS applicable clauses

• DoD DevSecOps Reference Design

• Executive Order 14028 (Software Supply Chain Security)

• DoD/AF SBOM and cybersecurity policy guidance

• Platform One DevSecOps architecture standards

4. Performance Requirements

4.1 Functional & Technical Requirements

1. The product must support generating SBOMs that comply with accepted industry standards (e.g., SPDX, CycloneDX)

2. The product must support generating SBOMs for common programming languages and ecosystems (e.g., npm, Maven, PyPI, Go modules, NuGet, RubyGems, Cargo).

3. The product must provide an API and or CLI to generate SBOMs during the build process (CI/CD).

4. The product should represent direct and transitive dependencies, including their relationships (e.g., which package depends on which).

5. Must support scanning container images

6. The product must include optional metadata about repository URLs and commit hashes for each component, when available.

7. Packages listed in SBOMs should also have the PURL format.

8. The software must integrate with standard vulnerability databases, such as the National

Vulnerability Database (NVD), RHSA, GHSA, and other vendor-specific feeds.

9. The product must be able to automatically check the discovered components in the

SBOM against known vulnerabilities.

10. The product must map identified vulnerabilities to industry-standard severity metrics

(e.g., CVSS scores).

11. The product should have mechanisms for users to mark or override false positives and provide context for false negatives.

12. The software must track changes over time to detect new vulnerabilities that affect older versions of the software.

13. Vulnerability feed content should be supplemented by custom data from security researchers to minimize false positives, especially when filtering out vulnerabilities that does not apply to containers

14. Product need to take a container image as an input and output a vulnerability result for the container image

15. Product must be able to consume a container image locally or hosted in a registry for scanning

16. Product needs to be able to consume VEX documents to propagate vulnerability context and justifications to minimize false positives

17. Product should have malware scanning

18. Product should have a policy engine to flag and specific Dockerfile instructions, with the ability to warn and stop based on specific conditions

19. Product should have the ability to lint a Dockerfile for best practices

20. Product should be able to retrieve metadata for files (permisisons, hashes, ownership) and have a policy engine to evaludate warning, passing, and failing conditions based on the metadata

21. Product has a policy engine that can be used to check containers against compliance standards such as DISA STIG and CIS

22. Product should have the ability to examine the content of files and evaluate policy rules based on content

23. Product should give the user the ability to make custom policies

24. Policies should be in structured format (Configuration as Code) and be able to imported via CLI and API

25. Product should have a GUI to display compliance standard items (like StigViewer)

26. The software must generate comprehensive reports listing all identified components, licenses, and known vulnerabilities.

27. The product should provide configurable alert channels (e.g., email, Slack, webhook) when new vulnerabilities are identified in existing SBOMs.

28. A dashboard should provide an at-a-glance view of vulnerability statuses, license compliance, and risk posture across multiple projects.

29. The product must support export of reports in various formats (HTML, PDF, JSON) to integrate with external systems or auditing tools.

30. The product's API and or CLI are compatible with common CI/CD tools like Gitlab CI, Github Actions, and Jenkins

31. The product should provide a plugin or extension mechanism that allows community-driven or custom vulnerability check modules.

32. The product should allow users to define security policies (e.g., fail builds on critical vulnerabilities)

33. Product must be horizontally scalable when analyzing containers - we containers should be able to be able to be analyzed in a distributed manner

34. Product should keep a database of vulnerability and compliance reports with images hashes to do quick lookup if the images submitted to be scanned are the same

35. The product itself must follow secure development lifecycle practices and be regularly tested for vulnerabilities (e.g., using SAST/DAST).

36. The software must support role-based access control (RBAC), single sign-on (SSO), and secure authentication protocols (OAuth, SAML).

37. The product must encrypt stored vulnerability data and SBOM artifacts at rest and support secure communication (TLS) in transit.

38. The product must produce detailed logs of scans, user actions, and configuration changes. Logs should be exportable to SIEM (Security Information and Event Management) systems.

39. The product should provide an intuitive web interface for non-technical stakeholders to view SBOMs, vulnerabilities, and generate reports.

40. The product should include links to reference material or best practices for handling common vulnerabilities.

41. The product must allow customization of reporting dashboards (e.g., reordering vulnerability lists by severity, adding custom fields) to fit organizational needs.

42. The product should support on-premises, cloud-based (SaaS), and hybrid deployments to fit different organizational policies.

43. Product should be deployable in Kubernetes with P1 Big Bang compatible helm charts

44. The product must provide clear instructions and/or automated tools for backing up and restoring configuration, logs, and scan results.

45. The product should allow seamless upgrades with minimal downtime and maintain backward compatibility where possible.

46. The product must have clear, up-to-date documentation and offer support channels (e.g., support portal, community forums, or dedicated contact).

47. Product should have the ability to easily let the user sync vuln feed to a disconnected environment

48. The product must undergo robust automated testing to ensure accuracy of SBOM generation, vulnerability detection, and reporting.

49. The product should include UAT cycles with representative end-users to validate usability, reporting accuracy, and integration with real pipelines.

50. Incorporate machine learning algorithms for recommending likely vulnerability impact or automated triage.

51. Provide advanced license compliance checks (e.g., license compatibility, potential license violations).

52. Support Scanning source code repository

5. Deliverables

• Software licenses/subscriptions

• Implementation and onboarding support

• Documentation and training

• Integration into CI/CD pipelines

• Ongoing technical support and vulnerability feed updates

• Authority to Operate (ATO) artifacts/support as required

6. Security & Compliance The solution shall comply with DoD cybersecurity requirements, enable deployment within secure enclaves, support RBAC, logging, and auditing, and align to Zero Trust principles.

7. Contractor Responsibilities Provide installation, configuration, sustainment, troubleshooting, and continuous improvement. Support integration with existing cloud and DevSecOps toolchains.

8. Government Responsibilities Provide access, hosting environment, pipeline integration points, and security approvals required for deployment.

9. Period of Performance Base year plus four (4) one-year option periods.