Review of level 1 activities #46
Conversation
There was a problem hiding this comment.
Looks good in general.
For the assessment attribute: It was written in a way that users understand what they have to provide in order to get it marked as implemented. I do not enforce that you re-write it, but for you know.
E.g.
The organization has a process for triaging and documenting false positives and accepted risks
could be
Provide a maximum one year old sample of a false positive or accepted finding including the date, description and date and expire date
| measure: | ||
| A well defined build process lowers the possibility of errors during | ||
| the build process. | ||
| A well-defined, automated, and auditable build process lowers the possibility of errors and unauthorized changes during the build process. It also enables traceability and rapid response to incidents. |
There was a problem hiding this comment.
How is it helping with "It also enables traceability and rapid response to incidents."?
There was a problem hiding this comment.
And: The sentence is not really a measure.
How about:
measure:
Find a tool that suits your environment. Add your manual build steps, include steps for running tests, scanning and preparation for deployment.
src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml
Outdated
Show resolved
Hide resolved
| Vulnerabilities with severity high or higher are added to the quality | ||
| gate. | ||
| description: | | ||
| All security problems that are rated as "high" or "critical" must be fixed before the software can be released or used in production. This means that if a serious vulnerability is found, it cannot be ignored or postponed. |
There was a problem hiding this comment.
The old text is not clear but leaves interpretation what "quality gate" is.
For known vulnerabilities, which one is better? Scanning for known vuln in prod or in the pipeline?
From my point of view scanning for known vuln. in prod is much more important than somewhere in a pipeline.
The problem arises because we do not have an extra SCA sub-dimension. It might be time to add it (not in this pr)?
There was a problem hiding this comment.
I think scanning the production environment is better than just scanning the pipeline.
Applications / services that are updated infrequently will "never" be scanned if we only do it in the pipeline.
And dependency vulnerability may "occur" after the application is deployed, without anyone changing a single line in the application.
SCA
Regarding a SCA sub-dimension: In a separate branch I have been adding more tags on activities. (Not yet pushed to your repo.) Tags such as 'scan', 'sca', 'sast', and 'dast'. That can also be used in the meantime. Without creating a totally new sub-dimension.
vbakke
left a comment
vbakke
left a comment
There was a problem hiding this comment.
Thank you for a thorough review.
Looks like I skipped Implementation and Test and Verification. I can try to add them soon.
However, could you please elaborate some on Default settings for intensity? The current text is very short, and I struggle to understand the boundaries for the activity.
| measure: | ||
| A well defined build process lowers the possibility of errors during | ||
| the build process. | ||
| A well-defined, automated, and auditable build process lowers the possibility of errors and unauthorized changes during the build process. It also enables traceability and rapid response to incidents. |
There was a problem hiding this comment.
And: The sentence is not really a measure.
How about:
measure:
Find a tool that suits your environment. Add your manual build steps, include steps for running tests, scanning and preparation for deployment.
src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml
Outdated
Show resolved
Hide resolved
| Vulnerabilities with severity high or higher are added to the quality | ||
| gate. | ||
| description: | | ||
| All security problems that are rated as "high" or "critical" must be fixed before the software can be released or used in production. This means that if a serious vulnerability is found, it cannot be ignored or postponed. |
There was a problem hiding this comment.
I think scanning the production environment is better than just scanning the pipeline.
Applications / services that are updated infrequently will "never" be scanned if we only do it in the pipeline.
And dependency vulnerability may "occur" after the application is deployed, without anyone changing a single line in the application.
SCA
Regarding a SCA sub-dimension: In a separate branch I have been adding more tags on activities. (Not yet pushed to your repo.) Tags such as 'scan', 'sca', 'sast', and 'dast'. That can also be used in the meantime. Without creating a totally new sub-dimension.
| A defined deployment process is a documented and automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. This process should include validation, approval, and rollback mechanisms. | ||
| risk: >- | ||
| Deployment of insecure or malfunctioning artifacts. | ||
| Deployment based human routines are error prone, and of insecure or malfunctioning artifacts. |
There was a problem hiding this comment.
yes, readme is well definied.
Building and testing of artifacts in virtual environments is there to not run all build jobs on the same server without isolation.
src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml
Outdated
Show resolved
Hide resolved
| risk: Attackers a gaining access to internal systems and application interfaces | ||
| measure: All internal systems are using simple authentication | ||
| assessment: | | ||
| - Demonstrate that every team member has appropriate access (least privilege). |
There was a problem hiding this comment.
From my point of view, it is the opposite:
- Demonstrate that every team member has least access as possible.
| Locally stored system logs can be manipulated by attackers unauthorized or might be corrupt or lost after an incident. In addition, it is hard to perform aggregation of logs. | ||
| measure: | | ||
| - Implement a centralized logging solution for all critical systems. | ||
| - System logs must be securely transmitted and stored in a central repository, protected from unauthorized access and modification. |
There was a problem hiding this comment.
"secure" transmission is not part of this activity
…b.com/vbakke/DevSecOps-MaturityModel-data into feat/v4-review-level-1-implementation
Feat/v4 review level 1 implementation
Split 'Defined deployment process' into 'Automated deployment process'
2 participants
Added missing descriptions and assessments, on level 1 activities.
Feel free to comment and adjust. I reckon we should aim to avoid repeating the same message in multiple attributes of the same activity. But I might still be doing that. Nice with more sets of eyes to improve...