Skip to main content

Jenkins CI Pipeline for Security Scans

This document describes the set of Jenkins CI Pipeline steps currently in use.

Context Diagram


Jenkins Workflow

OCCNE CI Job

  1. Gradle Build - using gradle, the available source is scanned using OWASP dependency checker, then a number of docker containers are created.
  2. Static Scan - using the McAfee malware scanner container (created in the Gradle Build step), all created docker containers are scanned for malware.
  3. Verify Build - Each docker container is loaded and the self test method is executed.
  4. Deploy - An OCCNE Deployment job is created and invoked.  (OCCNE CI Jobs may run in parallel - OCCNE Deploy Jobs are serialized.)

OCCNE Deploy Job

  1. Prepare Deploy - Wipe out any old cluster artifacts - get ready for a fresh deploy
  2. for (container in OS_Install, DB_Install,. K8s_install, Cfg_Install) do:
    1. Deploy_{{container}} - runs the named docker container
    2. Test_Deploy_{{container}} - verifies that the docker container operations were successful
  3. Scan CNE - using the cne_scan container, invoke the selected scan suites against the deployment target.

Here is an overview of the various deployment containers:

  • OS_Install - Loads and hardens an OS distribution onto the deployment target
  • DB_Install - Installs DBMS Software (MySQL) onto the DBMS deployment targets
  • K8S_Install - Installed Kubernetes onto the K8s deployment targets
  • Cfg_Install - Installs Common Service Components onto various deployment targets
  • CNE_Scan - deploys and executes a set of security scanners onto the deployment target

In general, the deployment targets are specifies using an Ansible host inventory file, and the deployment actions are encoded as Ansible playbooks delivered by the deployment container.

Container Self-Test

Each of the OC-CNE containers is delivered with a pair of tests pre-configured:

  • self-test - run in the Verify Build step, the self-test confirm that the container was built more or less correctly
  • cluster-test - run in the Test_Deploy_{{container}} step, the cluster tests confirm that the container payload was successfully installed on the deployment target system.

These container test tests are quite simple and do not perform and significant behavioral or functional tests.  Any complex testing will be performed using one or more dedicated test containers.  (In general, we do not want to deliver any complex test suites prepackaged in the application containers - tests should not be delivered or installed on customer sites per Oracle OSSA Guidelines.)

Dedicated Scan Container (CNE Scan)

When we want to verify CNE security posture, we will deliver a set of security scans to the target an run them. The scan container works similarly to the deployment containers - it uses the same Ansible host inventory file, and the scan actions are run via an Ansible Playbook.   The scans are organized into a suites, each suite documented by a playbook.  The playbook defines a number of Ansible tasks, each of which implement a specific scan in the scanner suite.

Initially, the following scanner suites are planned:

  • cis - Verifies the general hardening of the system; the following tests are available:
    • kube-bench - invokes the Kubernetes CIS conformance tests on worker and master node in the cluster
    • docker-bench-security - invokes the Docker CIS conformance tests on a node in the cluster
  • scap - performs a set of Security Content Automation Protocol (SCAP) driven tests
    • oval - performs an vulnerability assessment using published Common Vulnerabilities and Exposure (CVE) data
    • xccdf-standard - performs the standard configuration security assessment. (The Extensible Configuration Checklist Description Format (XCCDF) is a standard format for defining security checks.)
    • xccdf-rht-ccp - performs the standard Oracle Linux 7 Cloud Provider Security Scan
    • xccdf-stig-rhel7-disa - performs the Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) scans for Oracle Linux 7.


Using the CNE_SCAN_ARGS, Ansible tags can specified allowing for a specific suite or scan to be performed; here are some examples:

  • --tags=cis - runs just to cis scans
  • --skip-tags=cis - runs all the scans except for the cis scans
  • --tags=scap --skip-tags=oval - runs all of the scap scans, except for the oval scan.

The following tags have been defined and may be used to select scans:

  • cis
    • kube-bench
    • docker-bench-security
  • scap
    • oval
    • xccdf
      • xccdf-standard
      • xccdf-rht-ccp
      • xccdf-stig-rhel7-disa


Comments

Post a Comment

Popular posts from this blog

Supporting OpenTracing jaeger in spring boot applications

This page describes code changes in a typical spring-boot based application to support OpenTracing and jaeger. Instrumenting a tracer If you are creating a simple spring boot application that uses  spring-boot-starter-web , by default, the application does not support writing traces to jaeger. To support jaeger tracing, the first thing is to modify the build.gradle to add dependency of jaeger: dependencies {      implementation  'org.springframework.boot:spring-boot-starter-web'      implementation  'io.opentracing.contrib:opentracing-spring-web-starter:3.0.1'      // support opentracing jaeger      implementation  'io.opentracing.contrib:opentracing-spring-jaeger-starter:3.1.2'      testImplementation( 'org.springframework.boot:spring-boot-starter-test' ) {          exclude group:  'org.junit.vintage' , module:  'junit...
Post a Comment
Read more

HOWTO on implementing scanning into a CI Pipeline

Introduction As a part of the Software Security Assurance guidelines, we are required to perform various types of security scanning.  Security scanning is a specialized kind of testing that attempts to identify potential software bugs that could make a deployed application vulnerable to attack and compromise.  As with any testing, the tests can be manual or automatic, and they wan be performed at various points in the development cycle.   We can classify security scanning into three general categories: Static Application Security Testing (SAST)   - performed against source code / configuration data a static scan looks for common logic errors that might lead to system compromise. Dy namic Application Security Testing  (DAST)  - Performed against a running system, a dynamic scan looks for vulnerable software / configurations that might lead to system compromise. Security Monitoring  - Deployed as a part of the system, a security monitor co...
Post a Comment
Read more

Fortify Tooling User Guide

  Introduction The fortify-tools container is located within a shared repository in OCIR and requires a JWT to be able to access.  The variable WF_JWT will need to be set to a valid MAT You will want to choose one of three ways to use the Fortify SCA tooling: Integration Description Using the Fortify Tools Standalone to Scan a Project This is for using the tooling without integration in GitLab CI or Jenkins CI. Using the Fortify Tools In GitLab CI to Scan a Project This is for using the tooling against a project that whose code is hosted in GitLab and whose CI engine is GitLab CI. Using the Fortify Tools In Jenkins CI to Scan a Project This is for using the tooling against a project that whose code is hosted in GitLab and whose CI engine is Jenkins CI. Using the Fortify Tools Standalone to Scan a Project Simple Usage Run the Fortify Tools in a container docker run -t --rm -v <path to project source root directory>:/var/fortify/src phx.ocir.io/oraclegbudevcorp/cn-shared/s...
Post a Comment
Read more