DevSecOps 101

This is 4 parts tutorial on DevSecOps 101.

In part 1, we will learn how to detect and avoid vulnerable dependencies when developing applications.In the first step of DevSecOps, the first step towards building more secure apps is detecting and avoid using dependencies that have known vulnerabilities. This process is called Software Component Analysis or SCA. 

There are a few commercial options like Snyk, but for this tutorial, we will use the open-source pip package safety.

$ pip install safety

$ safety check --full-report

The 2nd step is to integrate SCA into the CI/CD process by adding GitHub workflow to our repository.

Next, we will perform analysis on the source code to find security vulnerabilities. This process is known as Static Application Security Testing, and this has been part of the enterprise software development lifecycle (SDLC) for years.

Recently, there are opensource tools like pylint, eslint or semgrep.

semgrep is, as its names suggest, like grep, but for source code. It allows developers to automatically find patterns in their source code while taking into account semantics like variable renaming. You can find an example of semgrep finding XSS in Django code here.

Even better, semgrep supports a lot of languages, and the semgrep community already has written plenty of rulesets to detect bad practices and security flaws for those.

$ pip install semgrep

$ semgrep --config "p/ci" --exclude .venv --error

•     --config "p/ci" means "use the community-written security rules for running in a ci environment"
•     --exclude .venv means "do not search for vulnerable source code in the .venv folder" (otherwise it would return hundreds of alerts!)
•     --error means return a non-zero error code if alerts are found. Useful for making the CI fail if insecure patterns are detected

Next, we need to add semgrep to the CI/CD to avoid ever doing the in the future. With this, we just installed a tool that scans all our python code to find insecure patterns, gives us recommendations on how to solve them, and integrates seamlessly into our CI/CD.

In part 3, we will be moving into Security Integration Testing (SIT) with automation.

To have an additional layer of security testing that is closer to the application's production context, security teams use specialized tools that will simulate attacks against the running application and report the successful ones.

This process is called Dynamic Application Security Testing (DAST).

Nuclei is an easy-to-use application security testing tool written in go-lang. It leverages the community to create new automated tests using simple YAML template files.  

$ go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest

$ docker-compose up

$ nuclei -u http://localhost:8080

Next, we will be integrating Nuclei inside the CI/CD process. Again,, in only a few steps, we just install a tool that scans for vulnerabilitites directly inside CI/CD. We scannd our live running app using nuclei web-app security scanner.

In part 4, we will be learning how to scan Docker images using Trivy. This is an opensource security scanner to find mis-configuration and vulnerabilities.

Thanks to trivy, one can scan its docker images to know literally in seconds if they contain packages with known vulnerabilities. Even cooler, trivy is free, open-source, and well maintained.

$  curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.21.0

$ docker build . --file Dockerfile.app -t dvpwa.app

$ trivy image dvpwa.app:latest

Lastly, we will be integrating trivy in GitHub Actions by following a template from AquaSec. So we just set up a tool that automatically detects vulnerable packages inside our docker images, directly in the CI/CD.

In fact trivy can scan way more than docker images: filesystems, requirements.txt, package.json, Dockerfiles and K8s configs.

$ trivy config .

This will scan Dockerfile.app and Docker.db automatic.

Links:

• DevSecOps 101 part 1: Detecting Insecure Dependencies (SCA)
• DevSecOps 101 Part 2: Detecting Insecure Source Code (SAST)
• DevSecOps 101 Part 3: Scanning Live Web Applications (DAST)
• DevSecOps 101 Part 4: Scanning Docker Images With Trivy
  
• Finding bugs with Nuclei with PinkDraconian (Robbe Van Roey) 
  

Fixing Bugs with Deep Learning

In a new paper, Self-Supervised Bug Detection and Repair, presented at the 2021 Conference on Neural Information Processing Systems (NeurIPS 2021), Microsoft show a promising deep learning model, called BugLab.

BugLab can be taught to detect and fix bugs, without using labelled data, through a “hide and seek” game. The goal of our work is to develop better AI that can automatically find and repair bugs.

BugLab uses two competing models that learn by playing a “hide and seek” game that is broadly inspired by generative adversarial networks (GAN).

For some samples, please check out the Microsoft blog at the link below.

Links:

• https://www.microsoft.com/en-us/research/blog/finding-and-fixing-bugs-with-deep-learning/
  

Building Security in Maturity Model

Software security again.

In 2006, software security found itself embodied in three major methodologies: Microsoft SDL, Cigital Touchpoints, and OWASP CLASP. Of course there are more. BSIMM selects 9 (out of 35 software security initiatives) and creates a Software Security Framework (SSF).

The BSIMM is about helping us to determine where our organization stands with respect to software security initiatives and what steps can be taken to make it more effective.

For a concise description of the BSIMM, read the informIT article Software [In]security: The Building Security In Maturity Model (BSIMM), Confessions of a Software Security Alchemist.

You can download the document from here.

Security in SDLC

The software development life cycle

The software development life cycle, or SDLC, encompasses all of the steps that an organization follows when it develops software tools or applications. Organizations that incorporate security in the SDLC benefit from products and applications that are secure by design. Those that fail to involve information security in the life cycle pay the price in the form of costly and disruptive events.

In an organization that's been around for several years or more, the SDLC is well-documented and usually includes the steps that are followed and in what order, the business functions and/or individuals responsible for carrying out the steps and information about where records are kept.

A typical SDLC model contains the following main functions:

• Conceptual definition. This is a basic description of the new product or program being developed, so that anyone reading it can understand the proposed project.
• Functional requirements and specifications. This is a list of requirements and specifications from a business function perspective.
• Technical requirements and specifications. This is a detailed description of technical requirements and specifications in technical terms.
• Design. This is where the formal detailed design of the product or program is developed.
• Coding. The actual development of software.
• Test. This is the formal testing phase.
• Implementation. This is where the software or product is installed in production.

Each major function consists of several tasks, perhaps documented in flowchart notation with inputs, outputs, reports, decisions and approvals. Some companies build workflow applications to support all of this.

Getting the right security information to the right people

Many people in the entire development process need all kinds of information, including security information, in a form that is useful to them. Here is the type of information that is required during each phase of the SDLC.

• Conceptual -- Organization information security principles and strategies
• Functional requirements and specifications -- Information security requirements
• Technical requirements and specifications -- Information security requirements
• Design -- Enterprise security architecture and security product standards
• Coding -- Development standards, practices, libraries and coding examples
• Testing -- Test plans that show how to verify each security requirement
• Implementation -- Procedures for integrating existing authentication, access controls, encryption, backup, etc.

If you are wondering why maintenance is omitted from the life cycle example here, it is because maintenance is just an iteration of the life cycle: when a change is needed, the entire process starts all over again. All of the validations that are present the first time through the life cycle are needed every time thereafter.

Finally, one may say that these changes represent a lot of extra work in a development project. This is not the case – these additions do not present that much extra time. These are but small additions that reap large benefits later on.

Approval: Moving to the next step

Organizations that use a software development life cycle process usually have approval steps at each major function. This takes the form of some kind of an approval meeting with the right stakeholders present: generally you find managers, directors, occasionally a VP – the people who control budgets, resources and business priorities.

Someone who represents information security should be present and have the authority to vote at most, if not all, major steps in the life cycle. If someone representing infosec is not present at a life cycle approval meeting, then there is a risk that a project lacking some key security component will be approved, only to become a problem in the future.

Fix it now or pay the price later

Organizations that fail to involve information security in the life cycle will pay the price in the form of costly and disruptive events. Many bad things can happen to information systems that lack the required security interfaces and characteristics. Some examples include:

• Orphan user accounts (still-active accounts that belong to employees or contractors who have left the organization) that exist because the information system does not integrate with an organization's identity management or single sign-on solution.
• Defaced Web sites as a result of systems that were not built to security standards and, therefore, include easily exploited weaknesses.
• Fraudulent transactions that occur because an application lacked adequate audit trails and/or the processes required to ensure they are examined and issues dealt with.

You should figure that problems like these are all costly to solve – in most cases far more costly than the little bit of extra effort required to build the products or applications correctly in the first place.