AppDat DevSecOps User Guide Guide #
The AppDat platform provides a “DevSecOps” launch security and compliance framework for the usage of the container hosting environments . AppDat provides this framework via managed “AutoDevOps” (ADO) template files that when composed together make up all the stages and jobs of the AppDat security and compliance pipelines.
Overview #
The AppDat ADO pipelines are broken down into the following stages, which process in sequential order. Stages are often only run on specific repository branches launch , the applicable branches for each stage are noted with the descriptions below. Additionally each stage can be either “automatic” or “manual”, where “manual” stages require user initiation clicking the “run” button to start the stage.
The AppDat ADO pipeline follows this high level process flow:
- Build new version of the container application and save to the AppDat container registry
- Perform security scans and tests against the new container application
- Automatically deploy application to staging/review environments
- Setup manual deployment of container application to production environment
Example Pipelines #
Non default (master) branches #
Default (master) branch #
1.0 Build stage #
- all branches
- automatic
The build stage is responsible for building the
docker container
launch
of the associated repository branch and commit that was responsible for triggering the pipeline. The application/service is essentially built with a traditional docker build...
command, which requires the repository to have a Dockerfile
.
Once the docker container has been built this stage commits the new “container image” launch to the AppDat Gitlab container registry associated with the associated project repository.
2.0 Test stage #
- all branches
- automatic
The test stage is responsible for the suite of security scanning jobs that AppDat enforces across all applications. The list of security and compliance scanning processes that AppDat employs in this stage grows as more capabilities are added, currently AppDat performs the following security and compliance scans:
- Container Scanning launch (required)
- Secret Detection launch (required)
- Static Application Security Testing (SAST) launch
- Dependency Scanning launch
- License Compliance launch
3.0 Review #
- non default (master) branches
- manual
The review stage is responsible for the deployment of a “review” version of the associated application. Review applications are used for temporary review of application updates prior to incorporation (merger) into the project’s default branch.
4.0 Dynamic Application Security Testing (DAST) #
- non default (master) branches
- automatic
The DAST stage is responsible for examining the application for vulnerabilities within a deployed application, DAST uses the open source OWASP Zed Attach Proxy launch .
5.0 Staging #
- default (master) branch only
- automatic
The Staging stage is responsible for the deployment of the application into the AppDat Staging environment.
6.0 Production #
- default (master) branch only
- manual
The Production stage is responsible for the deployment of the application into the AppDat Production environment.
7.0 Cleanup #
- all branches
The Cleanup stage is responsible for stopping the deployments of both the review and staging applications.
Setting up AppDat AutoDevOps #
The AppDat “AutoDevOps” (ADO) pipeline is a set of Gitlab CI/CD templates that can be easily incorporated into an AppDat customer project repository, and AppDat SRE will help establish the baseline ADO chart for an AppDat customer as part of a “New Application Deployment” deployment request.
There are multiple approaches an SRE may take when establishing a new DevSecOps process for applications and services depending on the complexity of the installation. For standard websites and for projects that can support a “monorepo” launch based approach, can simply include the AppDat ADO template directly with no modifications:
include:
- project: 'appdat/templates'
file: '/v3/AppDat-DevOps.gitlab-ci.yml'
More complex distributed systems that span multiple project repositories require more direct configurations from the AppDat SRE to setup the proper AppDat DevSecOps configurations. In these situations, an AppDat SRE will typically establish an infrastructure
repository within the customer’s group. This repository will then be responsible for the customized deployments for that set of application and services.