We’re all mostly familiar with DevOps, which a culture or methodology a company takes that enables quick deployment time. The main principles of DevOps in this case heavily relies on automation of several tasks, from build the program, running test cases, creating of environments, and deploying it to staging or production. The first two tasks of building the program and running test cases fall under Continuous Integration (CI) and the phase of deployment to staging and production fall under Continuous Deployment (CD)

While we have mentioned that DevOps speeds up deployment time, at the end of the deployment, there is usually a security check, or VAPT (Vulnerability Assessment/Penetration Testing). This checks are becoming more staple and required, with the rise in cyber security incidents involving data breaches and exploitation of services. To combat this, there has been talk about “Shifting Left” of the security practices. Doing this allows the several security issues to be addressed upfront, closer to where the development happens, and before any deployment is made to production.

Shifting these practices left covers many areas, from the code itself, to even the environment it is deployed in, and the infrastructure that it is hosted on. In this post, we cover briefly some of the areas, and what to look out for.

I like to break down the phases to Pre-Compilation, Post-Compilation, and Pre-Deployment. You would notice that there is no Post-Deployment, because if issues are found after deployment has happened, you have already failed.

Also, there are 5 areas of testing we want to cover:

1. Source Code
2. Libraries
3. Application
4. APIs
5. Infrastructure

We also split the automation process into the following 3 phases with their sub-activities

1. Pre-Compilation
   • White box testing
     • Source Code
     • Libraries
2. Post-Compilation
   • Black box testing
     • Application
     • API
3. Pre-Deployment
   • Configuration testing
     • Infrastructure

In the following sections, we talk more about the 5 areas of testing. It must be made clear that when we talk about security testing, it is vastly different from functionality testing. In functionality tests, we test if the functions work as expected. In security tests, we are assessing if the function is secure. Eventually, both functionality and security tests have to be put in place.

Source Code (White box testing)

Source code testing involves finding of strings that are deemed as insecure or private. Largely, this revolves around using grep to find those strings.

We categorize the strings as

• Insecure function calls
• Insecure data
• Private data

Insecure function calls are functions that are potentially dangerous, should they be exploited. Examples of such functions are exec or shell execution, or poorly formatted code that allows code injection. These are dangerous because it allows potential remote code execution. To catch these, we compile a list of insecure function calls, and we grep the source code to identify them.

Insecure data refers to pieces of information within the source code that may left there unintentionally, or due to poor coding practices. Examples of these are private keys, ssh keys, hashes, or hardcoded passwords. To identify these, we compile a list of patterns that resemble those data, and grep the source code to identify them

Finally, private data refers to any PII that may violate GDPR. Such information includes phone numbers, emails, credit card numbers, names, and any other information that may be deemed as a PII.

Resources

Grepping Insecure data

• https://github.com/securing/DumpsterDiver

Grepping Insecure function calls

• https://grepbugs.com/browse
• https://gist.github.com/nstarke/46cd0434b9735d90938a
• https://semgrep.dev/explore

Greping PII

• https://github.com/mmcatcd/pii-tool
• https://gist.github.com/dwallraff/ec0a640200bd1e9a3dc7f574e8d0165e

---

Libraries (White box testing)

In library scanning, what we are looking out for are vulnerable or outdated packages that are imported as part of the process of building the software. Depending on the the language used for the software, you may need to find the relevant scanners for those

Resources

Javascript libraries

• https://retirejs.github.io/retire.js/

OS Packages

• https://github.com/aquasecurity/trivy

---

Application Testing (Black box testing)

Once we have performed the white box testing and compiled the code, we then move to the black box testing, where we test the program while it is running. There are many ways to perform automated application testing, and the more common approaches are using OWASP ZAP together with Selenium.

OWASP ZAP is a free opensource solution used for scanning of web applications. It is able to perform quick scans for vulnerabilities such as SQL injection or XSS.

Selenium on the other hand is not exactly a web application scanning tool, but a web automation tool. It allows us to automatically perform actions on the website, such as logging in or filling up a form before sending it. Combing Selenium and ZAP as a proxy allows us to comprehensively test the website under various user scenarios

These are not the only options though, and there are many other tools such as SQLmap that can be used along with a custom wrapper. There may also be instances where you would want to write some test cases yourself.

Resources

Application Scanner

• https://owasp.org/www-project-zap/

Web Automation

• https://www.selenium.dev/

---

API Testing (Black box testing)

Aside from just testing the application itself, we also need to test all the APIs that are made available. In this, we are testing a few things:

• Functionality of the API (Does it work?)
• Correctness of the API (Does it work correctly?)
• Authentication and Authorization of the API (Is it protected?)

We can test the API for all of the above by sending payloads to the API, and inspecting the results. For example, we would send proper requests, malformed requests, and requests from various users and permission groups, and inspecting the results to see if they behave in the appropriate way.

We can generate the various malformed inputs with a fuzzer, or a list of known bad strings.

Resources

Application Scanner

• Curl
• https://www.postman.com/

Input Fuzzing

• https://www.digitalocean.com/community/tutorials/how-to-install-and-use-radamsa-to-fuzz-test-programs-and-network-services-on-ubuntu-18-04
• https://github.com/minimaxir/big-list-of-naughty-strings
• https://github.com/danielmiessler/SecLists

---

Infrastructure Testing (Pre-Deployment)

Finally, we test the infrastructure that is used for deployment. When deploying the application, we may need to choose the technology for the supporting OS, databases, communication channels, containerizations and many more. When we perform infrastructure testing, we are following guidelines to ensure that the environment and configurations are set to the most secure settings.

There are a few resources that guides us on how to carry out these configuration checks, such as Center for Internet Security (CIS), Security Technical Implementation Guidelines (STIGs), or OpenSCAP Security Guideline

In this phase, we also test for container security, to see if the image we are pulling is safe, and also if the configuration of the image is secure.

For deployments on the cloud, we also have to scan the cloud services. An example would be Amazon S3 bucket scanner.

Resources

• https://www.cisecurity.org/
• https://cyber.trackr.live/
• https://www.open-scap.org/
• https://docs.docker.com/engine/security/
• https://docs.docker.com/engine/scan/
• https://github.com/sa7mon/S3Scanner