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
Collaborators
in the GitHub repo must only be current developers, and contractors must not have more thanWrite
access - The
test
andprod
Environments in GitHub haveRequired reviewers
in the protection rules that must only be current users - The
RoleBindings
in the OpenShift-tools
,-dev
,-test
, and-prod
environments of thea12c97
anda191b5
namespaces must only be for currentUser
andServiceAccount
subjects - 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
, andprod
must only contain current users in the groupsRealm Administrator
,Realm Viewer
, andoperations-team
- The SSO CSS app in the
My Teams
tab 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 |