DevSecOps: Continuous Application Security

DevSecOps: Building a Secure Continuous Delivery Pipeline

Linkedin Learning - Instructor: Tim Chase

Prerequisites:

High-level DevOps understanding
General InfoSec knowledge
Scripting
Tooling:
- Python3
- JDK
- Docker
- SonarQube
- SonarScanner
- Zaproxy (Docker)
- ContrastSecurity
- WebGoat
- Anchore-Engine
- Anchore-CLI
- OWASP dependcy check
- Trufflehog

DevSecOps

DevSecOps is the integration of security into DevOps, extending CI/CD to security. Allows for security at scale.

Advantages of DevSecOps include:

Allow security to scale with DevOps teams
Security can quickly respond to events
Increased collaboration surrounding security

Goals of DevSecOps include:

Speed
Quality
Empowerment of DevOps teams

Application Security

Traditional AppSec

In traditional appsec, security is though as a separate team. Developers share code with the sec team. Security team run scans, etc.. and share report with dev team. Very manual and tedious. Not agile.

Continuous Integration

Check code several times a day
Lots of built-in automation (unit testing, static testing, etc..)
Leads to earlier and quicker detection of issues

Continuous Delivery

Follows continuous integration
Automated release process
Release timeline can be custom but automated

Continuous Deployment

Next-level CI/CD
Once test passes, code moves to production

Keyword: Continuous

Continuous Application Security

Continuous Static Testing

SAST: Static Application Security Testing

Analyzes source code for security vulnerabilities
Language-specific testing
Should be quick, accurate, API/CLI supported, bug tracker integration

Tool choice: Sonarqube / SonarScanner

Notes regarding docker install:

sysctl -w vm.max_map_count=524288
sysctl -w fs.file-max=131072
ulimit -n 131072
ulimit -u 8192

Docker Compose:

# Usage: docker compose up
version: "3"

services:
  sonarqube:
    image: sonarqube:community
    depends_on:
      - db
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: sonar
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
    ports:
      - "9000:9000"
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data

volumes:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_logs:
  postgresql:
  postgresql_data:

Once SonarQube is operational, ensure by navigating to http://<IP>:9000 and login with default credentials admin:admin. In order to verify functionality, clone the following Sonar Scanning Examples repo. Navigate to the sonarqube-scanner directory and run the docker sonarqube-scanner docker container, which will send the example source directory to the server for static analysis. Note: An authentication token must be generated prior to running the docker container. This can be accomplished by clicking on the profile icon, my account, and security. Then, run the following:

docker run \
    --rm \
    -e SONAR_HOST_URL="http://SONARQUBE_URL:PORT" \
    -e SONAR_LOGIN="myAuthenticationToken" \
    -v "/absolute/path/to/example/directory:/usr/src" \
    sonarsource/sonar-scanner-cli

A short while later, the text EXECUTION_SUCCESS should appear in the docker output and navigating to “Projects” in the WebUI should show the scan results.

Continuous Dynamic Testing

DAST: Dynamic Application Security Testing

Analyzes website for security vulnerabilities
Language agnostic
Black box testing
When running continuous, run asynchronously

Tool choice: ZapProxy

Helpful docs: https://www.zaproxy.org/docs/docker/baseline-scan/

Example usage: docker run -t owasp/zap2docker-stable zap-baseline.py -t https://www.example.com Ideal to be run in a CI/CD environment. Zap can optionally generate reports, which can be published to a shared dashboard for developers to review and update code.

Interactive Application Security Testing (IAST)

New way of reviewing apps
Works by integrating with runtime
Performs test while app in use
Continuous in nature - always on, always testing, always providing feedback

Tool choice: Contrast (requires sign-up)

Continuous Secret Scanning

Review code for keys, passwords, etc..
Important with Infrastructure as Code (IaC)
Useful when employed as a pre-commit hook

Tool choice: TruffleHog

Example usage (against remote repo):

docker container run -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys --json  > trufflehog.json
cat trufflehog.json | jq

Continuous Library Scanning

Application libraries are source of security concern
OWASP Top 10

Tool choice: OWASP Dependency Check

Continuous Container Scanning

Container Architecture
- One container for application
- Eases deployment and configuraiton
- Scripted install and config
Security Considerations
- Vulnerabilities ( CVEs, deprecated libs, etc..)
- Policies ( Best practices, keys in containers, SSH running, etc..)
- Runtime Detection (Container escape, unusual activites)

Tool choice: Grype

Example usage: grype image:tag

Tying it all Together

When it comes to the continuous application security testing, it must become a process. Incorporating these tools into a pipeline of sorts is a necessity in order for it to truly be continuous and agile.

Useful integrations:

Jenkins
OWASP glue

Another concern is the managing of results. Each tool supplies its own result, however exporting it all to a common format (ie JSON) and consolidating it into a centralized dashboard helps streamline the application security. OWASP DefectDojo is a platform that allows for the central visualization from many security tools.

Example Pipeline:

Create script to run tests
Push results to DefectDojo
Manage script and testing in Jenkins

Ari Yonaty