Main repository: https://code.il2.dso.mil/
Staging Site: https://appname.staging.dso.mil
Product manager:
Technical Point of Contact:
Launch Date/Deadline: TBD
Project Team To-Dos
1. Add your code to the GitLab repository for your project
2. Attend the Security Onboarding meeting
Before onboarding, the following documents must be added to your Doc Repo:
- CtF Onboarding Questionnaire *(new teams only)
- CtF Checklist
- Product Team Member List
- Text document with a list of targeted pipeline urls
3. Complete remaining forms and upload to Doc Repo
- Plan of Action
- System Security Plan
- Project Architecture Diagram
Note 3a: All applications must be integrated with Platform One Keycloak and reflected in the Architecture Diagram in order to receive a CtF.
Note 3b: Validate the architecture diagram is focusing on the component being validated (i.e. Grey out the other components). A good architecture diagram should give us a clear overview of a system. At a single glance, we can see which building blocks are being used, how they interlink, and how data flows between them. All ports and protocols should be indicated for all communications/interfaces. User roles should be indicated and described.
Note 3c: Documentation for Components/Microservices should reflect information consistently across their respective POA, SSP, and Architectural diagrams. In addition, that information should be consistent with what was identified in the SD Elements surveys. Over the course of development if the architecture changes, the SDE survey should be modified as well.
4. Review Gitlab - Pipeline(s)
GREEN Pipeline
Search for the name of the application in question under projects.
Note 4a: If trufflehog has a yellow "!" please verify that there are no secrets or passwords being committed. This can be done by clicking the "trufflehog" button in the pipeline, going to the right under "Job artifacts" and clicking "Download". Once the download is complete open the artifact using a editor such as Notepad++ and verify that there were no passwords/secrets found.
Select application (Listed as “[Business Unit name]/[Project Name]).
On the left sidebar, select CI/CD >“Pipelines.”
Verify the most current results of the pipeline are all green and have “passed."
Note 4b: E2E Testing- How to requirements
5. Review project scans
Fortify Static Analysis
- Select Application Version under dashboard.
- Select “Profile” – this is the toolbox icon on the upper right by “Filter Set” – next to the blue button for “+New Version.”
- Ensure that “Show suppressed issues” and “Show hidden issues” are selected – click Apply.
- Select “Audit” from the top middle menu.
- Verify there are no Critical, High, or Medium findings (The colored circles located right above the “Issue Name”).
- Any false positives, won't fix, suppressed, or hidden issues need to have comments/explanation from the App team and verified by the Platform (Mission DevSecOps) team.
- Compare number of scanned lines of code in Fortify to number of scanned lines of code in SonarQube (If these are not the same or close to the same it's likely a problem).
SonarQube Scan & Code Coverage
- Type the project name and select project
- Scroll down to “Coverage” and ensure the coverage is above 80%.
- Next, select “Issues” at the top of the page.
- On the left side panel under “Severity,” ensure that there are no Blocker, Critical or Major issues.
- On the left side panel under “Resolution,” select “False Positive”.
- Verify with App team/Platform team the “False Positive” is legitimate.
- Any false positives, won't fix, suppressed, or hidden issues need to have comments/explanation from the App team and verified by the Platform (Mission DevSecOps) team.
SonarQube Dependency Scans
- Type the project name and select project with “Dependencies” appended to the application name.
- Next, select “Issues” at the top of the page.
- On the left side panel under "Severity," ensure that there are no Blocker, Critical or Major issues.
- On the left side panel under “Resolution,” select “False Positive”.
- Verify with App team/Platform team the “False Positive” is legitimate.
- Provide comments on all "Fixed" items indicating how it was fixed.
- Any false positives, won't fix, suppressed, or hidden issues need to have comments/explanation from the App team and verified by the Platform (Mission DevSecOps) team.
6. SD Elements Tasks
- Complete and comment on all SD elements tasks ("Show only NIST tasks" should be checked)
Note 6a: Cybersecurity has culled the tasks in SD Elements and identified those that the pipeline or platform handles. If a task has a "platform" or "pipeline" tag on it that does not have the ability to be removed (an 'x' doesn't appear when you hover), the product team does not have to provide an answer. There will be an "official answer" in the "how-to's".
Note 6b: Complete means the product team has reviewed the task and the component is compliant with the requirement. Comments for tasks should include how the requirement is met/implemented. There are associated tests in the "testing" tab for many of the tasks that have you verify that the component is compliant. The testing task comments should document how the app team tested that it was done (there are how-to's in many of the testing tasks) and the subsequent result of the test. Don't be generic with comments.
Note 6c: SD Elements ingests SonarQube, OWASP dependency check and Fortify files to automate certain SDElement tasks. If the validation causes a fail(Red flag on the far right of the task), click on the red flag and the drop down arrow to see what caused the fail. In order for the task to not fail, those findings will need to be remediated regardless of their low, medium, high, critical ranking due to the finding mapping directly to NIST 800-53 requirements. Example: SD Elements T105 Verify that your application does not have unnecessary debug capability or leftover test/debug code: Fail due to 3 counts of dead code with a low ranking in fortify. These will need to be remediated for T105 to pass.
If all items above this line are complete, notify the CyberSecurity team in the Product Team Path to CtF MatterMost Channel that the application is ready for CyberSecurity team CtF Review.
CtF Review
- Provide the cybersecurity team tester with login/pwds and URLs for the front end and any API parameters used for backend testing. The cybersecurity team tester will validate some of the testing answers provided by the product team using non-malicious tests.
- Ensure any tasks returned by Cybersecurity with "re-visit" tag are addressed.
- Provide a risk mitigation strategy/burn down plan for any POA&M'd vulnerabilities or SDE tasks.
- Finalize CtF review with project assigned assessor.
- Work with cybersecurity team to schedule a CtF meeting with CISO.
After the CtF is Issued
- Provide monthly status through their respective MM CtF channel on any POA&M assigned to the application team.