SoAR and Compliance - bcgov/common-hosted-form-service GitHub Wiki
This documentation is no longer being updated. For the most up to date information please visit our techdocs
Home > About CHEFS > SoAR and Compliance
The Security Threat and Risk Assessment's (STRA) Statement of Acceptable Risks (SoAR) describes how the security of CHEFS is to be maintained. The following procedures are used to stay in compliance with the SoAR.
The SoAR section "Assessment", subsection "Access Control" states:
Access reviews are done regularly every month to ensure accounts are removed when no longer required.
CHEFS is on a two week sprint schedule, and this review happens every second sprint before the sprint planning meeting. Check the following access controls and remove stale user accounts:
- The
Collaboratorsin the GitHub repo must only be current developers, and contractors must not have more thanWriteaccess - The
testandprodEnvironments in GitHub haveRequired reviewersin the protection rules that must only be current users - The
RoleBindingsin the OpenShift-tools,-dev,-test, and-prodenvironments of thea12c97anda191b5namespaces must only be for currentUserandServiceAccountsubjects - SysDig access must only be for current team users (
oc -n a12c97-tools get sysdig-team a12c97-sysdigteam -o yaml) - The SSO environments
dev,test, andprodmust only contain current users in the groupsRealm Administrator,Realm Viewer, andoperations-team - The SSO CSS app in the
My Teamstab must only contain current users in theCoCo Team
Update the log at the end of this page to show that this step has been completed.
The SoAR section "Assessment", subsection "Vulnerability Management" states:
Advanced Cluster Security (ACS) is used by the CHEFS Team to identify, prioritize, and address security risks and vulnerabilities in the CHEFS application, including images, pods, and configurations.
CHEFS is on a two week sprint schedule, and this review happens before every sprint planning meeting. In Red Hat ACS ensure that the top item in the Images most at risk has a JIRA item created for it. If not, create a JIRA item in the Backlog using the template:
- Type: Task
- Title: ACS Image most at risk: <IMAGE_NAME>
-
Description:
The Red Hat Advanced Cluster Security (ACS) application has identified the image <IMAGE_NAME> as being most at risk. To satisfy the requirements outlined in the Security Threat and Risk Assessment's (STRA) Statement of Acceptable Risks (SoAR), this image must be updated to resolve fixable vulnerabilities (or mitigated in some other way, if updating the image is not possible). - Epic Link: CHEFS DevOps
Update the log at the end of this page to show that this step has been completed.
During sprint planning arrange for the new JIRA item to be included in the sprint.
The SoAR section "Assessment", subsection "Vulnerability Management" states:
GitHubβs Dependabot is enabled for enforced for security alerts. Dependency package security audits are done periodically for the main CHEFS image which is updated regularly.
CHEFS is on a two week sprint schedule, and this review happens before every sprint planning meeting. In the common-hosted-form-service GitHub repository check the Security > Dependabot alerts. Create a JIRA item in the Backlog for new alerts using the template:
- Type: Task
- Title: Dependabot Vulnerability Alert for <PACKAGE_NAME> in <MANIFEST_DIR>
-
Description:
The GitHub Dependabot process has created an alert for the <PACKAGE_NAME> dependency. To satisfy the requirements outlined in the Security Threat and Risk Assessment's (STRA) Statement of Acceptable Risks (SoAR), this vulnerability must be handled by updating the package version (or mitigated in some other way, if updating the package is not possible).
https://github.com/bcgov/common-hosted-form-service/security/dependabot/<DEPENDABOT_ID> - Epic Link: CHEFS DevOps
Update the log at the end of this page to show that this step has been completed.
During sprint planning arrange for the new JIRA item to be included in the sprint.
The SoAR section "Findings and Conclusion" states:
The CHEFS Team has remediated all medium vulnerabilities identified in OWASP ZAP scan conducted by NRS. Also, they have added the OWASP ZAP tool into the CHEFS development pipeline.
The ZAP scan vulnerabilities were remediated, and the GitHub Actions now run the scans with every build. Manual steps are needed to check the scan results to see if new vulnerabilities exist.
CHEFS is on a two week sprint schedule, and this review happens before every sprint planning meeting. In the common-hosted-form-service GitHub repository open the Issue called ZAP Full Scan Report. At the bottom of the issue follow the link to retrieve the zap_scan artifact. Create a JIRA item in the Backlog for new alerts using the template:
- Type: Task
- Title: OWASP ZAP Scan Vulnerability <VULNERABILITY_NAME>
-
Description:
The OWASP Zap Scan process has identified a <VULNERABILITY_RISK_LEVEL> risk level vulnerability:
> <VULNERABILITY_DESCRIPTION>
To satisfy the requirements outlined in the Security Threat and Risk Assessment's (STRA) Statement of Acceptable Risks (SoAR), this vulnerability must be remediated. - Epic Link: CHEFS DevOps
Update the log at the end of this page to show that this step has been completed.
During sprint planning arrange for the new JIRA item to be included in the sprint.
| Date | Access Review | ACS | Dependabot | OWASP Zap Scan |
|---|---|---|---|---|
| 2023-12-07 | β | β | β | β |
| 2023-11-01 | β | β | β | Wait for Vue3 |
| 2023-10-12 | β | β | β | Wait for Vue3 |