Implementing DevSecOps rings for shifting Security left and what that means is that Security is considered right from the start of each sprint, through the project design, coding, CI/CD, build, etc to ensure security best practices before release.

DevSecOps workflow is a sequence of steps that spells out security best practices for software development from initiation to completion and this workflow is designed in line with the organization’s unique SDLC stages and the security concerns they wish to check.

Developers and team members who have access to the code repositories should ensure that they have secure coding practices in place. The first commit that goes into a project should be verifiable. In a workflow, the developers' concerns come first since security is a shared responsibility of all the parties involved. Anyone with access to commit should ensure that their actions are verifiable. Whatever changes they make can be verified.

Developers Control

• Having a version control system

• Accept only signed commits to prevent unauthorized changes going into the main branches of the code and enforce source code integrity for changes made to source code.

• Enforce pull requests for changes to the main branch - there should be both manual and automated pull request reviews. Pull requests can be reviewed to check Security Vulnerabilities or malicious changes.

• IDE integrations for Static Code Analysis. (Static Application Security Testing, SAST and Software Composition Analysis, SCA).

• Enforcing quality gating for SCA will enable developers to find out about vulnerabilities at the earliest stage before they get to the CI/CD platform.

CI/CD control

• Restrictions on CI/CD platform. What this means is that the CI/CD process or Pipeline should not be configurable by anybody to prevent unauthorized users from having access to or modifying the code in the pipeline. Configuration of the CI/CD is strict to only some limited individuals like the DevOps engineers, senior leads, product managers, etc.

• Defined build and deployment process - this ensures that there is a template, a pattern that rolls out how applications get built and deployed to enable the engineers who have access to the pipeline to control and audit the process and this template should be secured.

• Restricted access to credentials or sensitive deployment parameters that should not be included in the code even though they are part of the build process for the project. Eg. Code secrets.

Build Control

Issues around software dependencies

• Since software dependencies are published in a registry that you may not have control of. It is not safe to say that those registries have not been compromised. Organizations can have their private package registry where they push their software packages.

• Software Composition Analysis - this helps to weed out or identify packages that have Vulnerabilities.

• SBOM analysis and signing- the essence of the software bill of materials is to prevent Attacks like dependency injections.

• Static Application Security Testing - this is to verify that secure coding practices were used.

• Sign software artefacts Deployment Perform static analysis especially when there is IaC integration. Verify software artifacts. This will ensure a generation of provenance regarding the software used to build an application. This activity is not performed on the CI/CD itself but is necessary as it is part of the deployment activity.

Approval

This is a way of approving that no changes were made

• Verify the build process

• Two-person review for pull requests.

Note: for a production environment, approval should come before the deployment

Monitoring

• application and infrastructure monitoring to detect any abnormal activity.

• Log collection and visualization.

• Automated incident alerting and response mechanisms should be in place.

• Continues scanning after deployment to ensure that the dependencies used in building that software are still intact and have not faced any compromise.

Feedback(alerting)

• Alerting and ticket creation systems. Jira and other alerting platforms are good for managing tickets and events.

• Vulnerability management systems.

Scenario:

Have been employed as a Security Engineer to implement DevSecOps practices within company XYZ’s software development practices. Company XYZ’s security concerns are not limited to but include the following:

• Supply chain attacks

• Unauthorized access to code

• Unauthorized commits

• Tampering with the build and deployment processes i.e CI/CD

• Tampering with software dependencies.

• Tampering with software artifacts

Application security vulnerabilities

• Insecure code

• Vulnerable software dependencies

• Vulnerable application infrastructure

My task: Design a workflow with solutions that will address company XYZ’s challenges and any other possible additional security concerns not listed above.

I used draw.io to make this drawing looking stating the security measures that should be put in place to cushion the security challenges listed above and/or any other security challenges that are likely to be faced.