🛠 Atypical DevSecOps practices for CI/CD
Salute,
Let’s continue to look towards DevSecOps practices and this time we’ll discuss CI/CD, where I want to share with you the developed principles that I consider relevant and basic when developing concepts.
Continuous Integration/Continuous Delivery is the automation of development processes, which includes continuous integration and continuous delivery. Automation is aimed at the SDLC cycle.
Now let’s look at the practices themselves and start with the base:
- Controller isolation: assemblies are not on the embedded node, but are initialized from global variables
- It is not allowed to have unused environment variables
- Do not run the assembly from ACE with privileged rights
- Build and deployment tools should not require increased access rights
- Ensure strict rendering of user content: files from working directories, archived artifacts, etc.
- During the CI\CD process, the possibility of overflows and unauthorized overwriting must be excluded.
- It is not allowed to call external dependencies at the deployment stage
Stages
- Each Stage is isolated and separates operations functionally
- Accounts used or called during a build or deployment must be pre-authenticated:
- authentication must be personal and provide the ability to track actions;
- authentication must be provided for users of all access levels (administrators, supervisors)
- All jobs must be divided according to purpose: CI (assembly, testing, code analysis, etc. - separately and does not interact with operating environments, and CD uses separate US
- Libraries, assemblies and pipeline templates should be stored separately from the control config
- It is recommended to use separate repositories for assemblies and templates to isolate configurations
- Included scripts: Groovy, Shell, Python, etc. must not contain checks or conditions that allow bypassing build, test, or other critical stages of the pipeline
- To ensure integrity and change tracking, a hash of the pipeline profile or configuration should be automatically collected on every build
- At the CD stage, a profile hash check is required
Features
- Below the maintainer there is no opportunity to independently choose the environment and be limited
- Deployment should not be performed without MR
- All pre-actions must include full artifact metadata - build parameters, delivery attributes and version IDs
- All callback actions inside the pipeline,
- Build, etc. should only run on applications packaged in Docker containers for consistent environments
- It is recommended to run several types of tests in CI: integration tests, unit tests, regression tests
- If the build is unsuccessful, the artifact should not be added to the artifact repository
- Deployment environments: staging, production, etc. must be logically and physically separated
- All post actions in the pipeline should not be called independently and must be executed only after the completion of the corresponding pre- or main stages
In summary: the above principles, when followed, reduce information security risks for the pipeline and help you control the pipeline itself, therefore, by following them, you can also build a high-quality development process. To shape further development towards automation of the Security predictor in DevOps, you can rely on them.
#appsec #devsecops #reco #specialty #pmcases