Complete Body of Evidence¶
This guide walks you through how to complete all sections of a Body of Evidence (BoE) to ensure alignment with the designated Impact Level (IL) of your deployment.
The Deployment Information form captures key technical and operational details about your application. Accurate and complete entries help the Game Warden security team evaluate your system’s configuration and ensure compliance with DoD ATO requirements.
Below is a breakdown of each required field with guidance:
| Field | Guidance |
|---|---|
| Operational Environment | Describe the environment where your application will run, such as:
|
| Authorization Status | Select from the available options to indicate the deployment's current status:
|
| Assessment Date | Provide the planned or completed date of the security assessment. Second Front is responsible for completing this field. |
| Security Reassess Interval | This is the interval at which your system’s security posture will be re-evaluated by Second Front. It should align with the security timeline outlined in the CtF authorization document. Consult your Technical Implementation Manager for more information. |
| List of Programming Languages | Provide a comprehensive list of all programming languages used to build your application (e.g., Python, JavaScript, Go). Include any backend or scripting languages relevant to deployed services. |
| List of Dependencies | List the services your application depends on — whether managed by Game Warden (e.g., AWS S3, SES) or managed by your team (e.g., external data connections or in-boundary containers/services deployed by the customer). Note: All dependencies should be reflected in the Authorization Boundary diagram. |
| List of Databases | Indicate the type and technology used (e.g., PostgreSQL, MongoDB, DynamoDB). Mention whether it is managed by the customer or uses a Bedrock service. |
Tip
- Be as specific and complete as possible.
- Coordinate with your security and engineering teams to validate this information before submission.
The Information Security form documents the sensitivity of the data your application handles and the security controls in place to ensure it aligns with DoD confidentiality, integrity, availability expectations, and data protection requirements.
Complete each field based on your current or planned deployment:
| Field | Guidance |
|---|---|
| Confidentiality | Confidentiality values are derived from security categorization of the application in tandem with your Mission Owner. |
| Integrity Level | Integrity values are derived from security categorization of the application in tandem with your Mission Owner. |
| Availability Level | Availability values are derived from security categorization of the application in tandem with your Mission Owner. |
| Classification Level |
Select the data classification your application will handle (e.g., Unclassified, CUI, Secret, TS/SCI, TS/SAP). This should align with the approved IL level of your deployment. Note:
|
| Distribution Control Type | Indicate any restrictions on data dissemination, such as NOFORN, ITAR, HIPAA, or FEDCON. |
| Controlled Unclassified Information (CUI) |
Select applicable high-level CUI categories (e.g., NNPI, Intel, PRVCY, OPSEC, Other). Because each high-level category can cover many specific data types, you must list the exact types of CUI present in your application (e.g., biometric data, health records, personnel security clearance forms). Note:
|
Tip
- Coordinate with your mission owner or security officer to confirm data types and classification.
- Ensure your confidentiality, integrity, and availability levels align with the system's operational context and compliance obligations.
- Be specific—general statements may delay approval.
Provide the version currently in use for each of the images in your application.
Important
- Images are updated to the current versions and match the versions reflected in your authorized environment.
- If an image will not be included in the application for which the CtF is being pursued, select Excluded from the dropdown.
- Review and attest to authorize the deployment of the selected services.
An Authorization Boundary Diagram (ABD) is a visual representation of your system’s software components, data flows, and security boundaries. As part of the BoE, you must provide a diagram that includes any external systems or services your application connects to outside of its deployment boundary. Include the system name, purpose, and any sensitive data exchanged.
See Authorization Boundary Diagram for more information.
The Role Identification form captures key stakeholders responsible for overseeing and supporting your application deployment in Game Warden.
You must provide the following details for each required role:
- Full Name
- Title
- Organization
- Email Address
- Phone Number
Required roles
| Role | Description |
|---|---|
| Government System Owner | The government official ultimately responsible for the application and its operation within the DoD environment. This person ensures the system complies with security requirements and approves changes or risk decisions. |
| Government Contract Sponsor | The government representative responsible for funding and contractual oversight of the deployment. They are often the primary liaison between the government customer and your company. |
| Government Prime Contractor | If your company is a subcontractor, this field should identify the prime contractor accountable for contract delivery. If you're the prime, indicate your own company’s contracting POC. |
| Company Product Owner | The individual at your company responsible for application functionality and delivery. They are expected to be the primary point of contact for questions about feature development and app roadmap. |
| Company Security Manager | The security lead within your organization who ensures that security practices align with Game Warden requirements. This person will also coordinate with the Game Warden Security team during incidents or audits. |
You must provide at least two to three emergency contacts for each deployment.
Required fields for each contact
| Field | Description |
|---|---|
| Full Name | The full name of the emergency contact. |
| A monitored email address to reach the contact quickly. | |
| Phone | A direct phone number, preferably a mobile number, for urgent communication. |
| Title | The individual’s job title or role (e.g., DevOps Engineer, Security Lead). |
| Preferred Contact | Indicate the preferred method of contact (e.g., email, phone, both). |
Important
- This section is required. It ensures that Second Front can contact the appropriate individuals in case of emergency events—such as outages, zero-day vulnerabilities, or critical security incidents—affecting your application.
- Ensure that the listed contacts are aware of their responsibilities and authorized to act on behalf of your organization during incidents.
For deployments in Impact Level 4 (IL4) or Impact Level 5 (IL5) environments, personnel must possess a valid Government Access Card—such as a CAC (Common Access Card), ECA (External Certificate Authority), or PIV (Personal Identity Verification)—in order to access the environment, including system logs.
You must provide information for all company personnel and engineers who hold applicable Government Access Cards and will be involved with this application.
Required fields for each CAC holder
| Field | Description |
|---|---|
| Full Name | The full name of the individual holding the access card. |
| Title | Their job title or role within the company. |
| DoD Number | The ID number found on the back of the CAC (e.g., DoDID#). |
| Expiration Date | The expiration date printed on the access card. |
Important
Ensure all listed information is accurate and up to date to avoid access delays during IL4/IL5 deployment or support activities.
Upload the results from the Static Application Security Testing (SAST) you've performed on your application. SAST artifacts must be current — no older than 30 days before submission.
Documents results from the Dynamic Application Security Testing, used to detect runtime vulnerabilities. Second Front (2F) Systems performs and includes DAST artifacts in your application’s Authorization Package.
Based on their review of your application, Second Front security team will upload this document to confirm that your development practices align with the Secure Software Development Framework (SSDF), as required by DoD guidance.
The AI Attestation section collects details about how your application uses Artificial Intelligence (AI) and/or Machine Learning (ML).
1. AI/ML usage
Start by confirming whether your application incorporates AI and/or ML technologies:
-
Artificial Intelligence: Does your application use any AI-related functionality?
- Select Yes if AI is used in any form (e.g., chatbots, recommendation systems, automation).
- Select No if your application has no AI features.
-
Machine Learning: Does your application use machine learning algorithms or models?
- Select Yes if ML is used for tasks such as prediction, classification, or pattern detection.
- Select No if ML is not part of your application.
2. Business case
Explain the reasoning behind your use of AI and the problems it solves:
-
Why does your application require AI? - Provide a concise explanation (e.g., "to automate document classification").
-
What use case(s) are addressed by AI and what value is expected to be realized? - Describe how AI improves your application and what benefits it delivers (e.g., better user experience, improved accuracy).
3. Type of AI
Select the types of AI used in your application:
- Predictive Analytics
- Machine Learning
- Deep Learning
- Natural Language Processing
- Computer Vision
- Reinforcement Learning
- Ensemble Model
- Generative AI
4. Machine Learning details
If your application uses ML:
-
Specify the Model Type
- Supervised Machine Learning
- Unsupervised Machine Learning
- Reinforcement Machine Learning
-
Are you using a foundational pre-trained model? - Select Yes or No.
-
Have you done additional training on the model? - Select Yes or No.
5. Machine Learning security
Provide responses to the following security considerations:
- Is customer data fed back into the model?
- What type of threat modeling was performed?
- Was vulnerability scanning performed? What tools were used?
- Was red teaming conducted? Who performed the testing and what were the results?
- How does the application prevent spilling data in the form of output?
- I verify that this application has considered and addressed the OWASP Top 10 for LLMs and Generative AI Apps.
6. DoD AI requirements
Explain how your application adheres to the DoD's Ethical Principles for AI:
| Principle | Guidance |
|---|---|
| Responsible | Describe how appropriate judgment and oversight are ensured throughout the AI lifecycle. |
| Equitable | Identify how your team works to minimize bias in data and models. |
| Traceable | Explain how development processes, decisions, and data sources are auditable and transparent. |
| Reliable | Describe your testing and assurance methods to validate AI safety and performance. |
| Governable | Outline how the system can detect, prevent, and shut down unintended behaviors. |
Second Front will upload to this section the risk recommendation memo — signed by a security control assessor or delegated representative — confirming authorization recommendation to the intended Impact Level and risk level determination of the application.
If you’re unsure how to complete the BoE, contact your Second Front implementation engineer.
BoE for Commercial Deployment environment
If you're deploying into the Commercial Deployment environment, your BoE does not require the following sections:
- Information Security
- Role Identification
- CAC Personnel
- SSDF Attestation
- CtF Recommendation Memo