Continuous Agile Application Security

The main thing about doing application development security now is not only being able to fit into the Agile process, but to be able tailor your current processes to run as part of the Constant Integration/Constant Development (CI/CD) process. This means that the old processes that drove static and dynamic code scanners (e.g. Fortify, Veracode, etc.) for the past 10 or more years, where coders check in their code, wait, and then get an answer, are out. Your process needs to be iterable (happen each time a developer checks in code) and automated (it has to happen automatically, so you don’t slow down the pace of the CI/CD process).

The CI/CD process has become software driven: software is written and then is checked in by software (a process orchestrator, e.g. Jenkins) and is stored by software in a code repository (e.g. Github). As the software is checked in, the AppSec Tester needs to be able to spawn a process that gets a copy of the code, runs it through its tests, and reports the results back to the coder and the CI/CD Agile process. This all needs to take place not in the hour(s) of our previous processes’ timescales, but in the minutes that the CI/CD is based on (I usually use the coffee cup test: if the scanning and reporting process takes more than it takes to getup, get a cup of coffee and chat (about 15 minutes), something is probably wrong.

Source: https://miro.medium.com/max/541/0*8zmHcgGpZnH26fcX

The architecture of this process falls into several steps you need to plan out and code for. This will turn you from a code checker into a coder yourself. You will be writing code to automate the process of checking code. As coding is done in a virtual environment these days, you need to be able to adapt this architecture to an internal cloud or an externally hosted private cloud. You can find this material on a lot of on-line courses and none of what I’m going write below is more evolutionary not revolutionary.

One caution: we are only dealing with testing the code itself as it is being written: this is called static code scanning. Every piece of code should go through this. There a whole other process to consider to test your code for vulnerabilities when it is running: this is called dynamic code scanning. That is another topic.

First, you’ll need to start with a virtual machine. This is your logical isolation layer from the rest of the cloud environment. You will also need to install a container manager such as docker on the VM. This allows you to have a clean logical separation of processes for your code scanning processes. This all needs to be scripted/written/coded in an infrastructure enablement language, e.g. Terraform, Ansible, etc. so that you can tear down and recreate the whole architecture as needed. More on that in another article.

You’ll want to setup a sample vulnerable application in a container so that you have a reference to measure your process against, so that you know its working when you point it towards all the coder developed applications. A simple one is Gruyere, from google-gruyere.appspot.com . You can pull it down using gitclone. Assuming you have a docker environment running:

1. sudo service docker start

2. git clone --depth=50 --branch=location of gruyere git repo

3. sudo docker pull gruyere:latest

Now start the container so that Gruyere is up on container with localhost:8008: docker run —rm -d -p 8008:8008 namesofyourgruyere:latest. Gruyere’s code is full of vulnerabilities to things that security people need to be able to detect and identify: code injection, cross site scripting. Try some manually before you automate.

The next step is to automate your attacks/detections for vulnerabilities. This means yet another container where you will stick in your scanning/detection engine software. This could be as enterprise ready as Fortify or Veracode, as cutting edge as Semmle, or as freeware as Arachni and Gauntlt (Gauntlt.org). It depends on the needs of your organization, and the conversations you will need to have about “false positives”, which is a whole other article. There is documentation on each of their websites on how to combine them together.

So let’s say now you’ve chosen and bundled up a scanning engine. You need to point it to its target (the code you are evaluating) and point some attacks against it (like the OWASP list).

$ sudo docker run -t --rm -v $(pwd):/workingdir -w ./SCANNING SOFTWARE ./ATTACK FILE

The attack file is the input into your scanning software and tells that software what vulnerabilities to try to exploit. You want to go down a complete list and you can check against the OWASP lists (https://owasp.org/www-community/vulnerabilities/, as a first step: https://owasp.org/www-project-top-ten/) and the Common Weakness Enumeration https://cwe.mitre.org/data/ for the most useful vulnerabilities to test. This will give your outputs which need to be fed back into the CI/CD pipeline, e.g. back into Jenkins, or whatever work flow organizer your Application Dev teams use. The current workflow tools have apis that many of the software scanners can use. Again, some programming and trail and error can let you built out that interface (the vendor can help also).

Your AppDev teams will not like this at first (trying to be tactful), but when they get immediate feedback, and don’t have to wait for you to run scans all the time, they will start to see the utility of this addition to the CI/CD process. You can strengthen the feedback loop by pointing them to training on how to code around their issues (I’d have loved this as a coder). Most of the better scanning software comes with this built in, and you can also point coders to the Mitre CWE site (https://cwe.mitre.org/data/definitions/699.html) which gives coders a wealth of information and examples in several of the most popular programming languages to incorporate into their code.

So that automates the middle and end of the CI/CD process for AppDev testing. We also need to automate the input process and the overall process. When the developer checks in her code, you need to fork another process that kicks off the code scanning process, and reports back the information to them at the end. This can be done several ways depending on the tools that you and the AppDev groups are using. At work I use Jenkins as an “orchestration” server: it acts as the hub of your CI/CD system. Fortify can be integrated into it, Veracode can. Your code scanner probably can also with some work.

The steps you want to build into your orchestration server are:

• Check for new code checked in. Anytime new code is checked in you should be firing this process.

• Set your environmental variables to the target code and the orchestration server.

• Run docker for the code scanning tool with your n attacks: this is just multiple statements of sudo command above running the code scanner with the attack input files.

  • Make sure your attack files are updated so that they are using env variables that you are feeding in from the 2nd step.

• Collect your output and feed it back into the Ci/CD process orchestrator. This is using the api in the code orchestrator to pass information back and forth so that the coders know they have vulnerabilities to fix.

This level of automation is where you need to bring your static code scanning process. Otherwise, you will not be able to keep up with the flow and volume of code generated during an Agile CI/CD process. You also do not have the time, money and resources to be able to attend every Agile scrum. This substitutes for that so that coders (or that one coder on each team who is the App Dev interface to App Security) only have to call you when something goes wrong.

It also lets you concentrate on improving and reporting on the process: the number of vulnerabilities you find, the number you can fix and close, and the number you accept into production and mitigate around, per application per team per business area responsible will have a direct feed into the overall quantitative risk posture of the firm that is getting reported upward to the Risk committees and the Board. (More on that later.)