In this article, we will approach different ways (and their pros and cons) to set up an Application Security Testing (AST) tool in a CI/CD pipeline. This is based on the learning related to our experience in taking care of this process in over 50 different companies, accounting for some tens of thousands of assets and delivery pipeline.
Background
To simplify the scope, we will only talk about SAST tools, but the context applied here is also equivalent to a good part of the setups proposed by SCA and IaC tools.
These setup proposals for AST tools, usually made by security tools vendors, aim to make the developer’s life simpler, so that he can quickly configure the security tool and take advantage of its benefits.
It is very common that, when we have complex problems and a “simple solution” proposal is made, some things have been ignored by the author of the proposal, with the main intention of just selling something.
In the case of Application Security Testing tools, usually these proposals have some points of attention:
1. It is common to have only one configured branch: usually this branch is the old “master” maybe your repository defaults to “main”. Also consider running the AST analysis on a “staging” branch, often referred to as “develop” or “staging”, as vulnerabilities will be caught earlier in development time.
2. Pay attention to the moment when the event for the analysis to take place is triggered: most security tools only consider an event, pull or push, when in fact, it is important that both are specified. In this way, code analysis coverage can be increased.
3. In addition to code diffs between commits, do you have a full codebase analysis at any point? This question is interesting because most tools consider:
- Only diffs, that is, only files that have been modified and specifically these modified sections, will be analyzed by the SAST tool. And this is a problem, after all, a codebase may have vulnerabilities in a specific section that was never modified after the insertion of the SAST, so the tool will not analyze these other sections.
- Some providers will tell you that in the new integrations, the entire codebase will be considered and therefore there is no problem with future analyzes only from the diffs, but in fact there is one more point that makes it necessary to schedule this from time to time to analyze the full codebase: SAST rules may evolve/change. A codebase that has only gone through full analysis from the start, at setup time, may not benefit from new rules. A code with problem/vulnerability (detectable by these possible new rules) would only be identified if it were modified.
Objective
Below is a reflection of the current initial proposal for setting up Conviso Platform for pipelines using Github Actions, which does not cover all the points that were listed in the background section.
name: CI
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
conviso-ast:
runs-on: ubuntu-latest
container:
image: convisoappsec/flowcli
env:
- FLOW_API_KEY: ${{secrets.CONVISO_API_KEY}}
- FLOW_PROJECT_CODE: "<project code>"
steps:
- uses: actions/checkout@v3
- name: AST
run: conviso ast ru
This way, the objective is to make the necessary changes considering the possible points of attention listed above so that our customers do not face such pains, but instead benefit from a well-structured setup.
Read also: Securing your code on GitHub with Conviso Platform integration
Proposal
Add the “main” branch to solve the first recommendation provided in the background section, so that you recall that multiple branches can be configured as well.
As for second recommendation, it was already considered in our proposal, both pull and push are specified.
In reference to topic number 3, we can make use of the schedule resource, specifying a period using cron syntax. In the example, it will be executed on the 5th day of each month, on Wednesday at 14:15.
name: Conviso Platform AST
on:
push:
branches: [ "master", "main" ]
pull_request:
branches: [ "master", "main" ]
schedule:
- cron: '15 14 5 * *'
jobs:
conviso-ast:
runs-on: ubuntu-latest
container:
image: convisoappsec/flowcli
env:
FLOW_API_KEY: ${{secrets.CONVISO_API_KEY}}
FLOW_PROJECT_CODE: ${{secrets.CONVISO_PROJECT_CODE}}
steps:
- uses: actions/checkout@v3
- name: AST
run: conviso ast ru
Conclusion
This proposal aggressively improves the efficiency of this category of analysis by ensuring better code coverage and use of updated SAST rules. However, the volume of code analyzed will be higher, if the manufacturer of your SAST tool charges based on the amount of lines analyzed (the industry standard), your cost will probably increase. Another cost that may increase is that of your CI/CD tool, in this case Github Actions, as it will now be triggered more often.
Remember, any technical decision always has a downside. If you’re making a decision believing you won’t have it, it’s probably because of your poor understanding of the solution or problem.
