With what is happening around the world security is taken topmost priority. One incident can destroy brand recognition & company’s reputation if not taken care in early phases. 50% of data breaches are happening because of web attacks. Current attacks are more & more financially motivated rather than just destruction, which is a another shift. The attacks have become more sophisticated & so is the way of security handling either in application or infrastructure code. I thought it will be a good topic to write on & share my experience with the rest of the community. Please feel free to comment on this article.
To most extent I am using CI/CD as an implementation of DevOps as I believe the success of DevOps heavily hinges on how properly CI/CD is implemented or what degree of automation is available to the developers’ disposal.
SAST (Static Application Security Testing ):- Most of us are aware of this type of code analyzer testing for a long time. Tools in this category runs against proprietary code. These tools are specific to language It is done during the earlier lifecycle of CI/CD. These tools are language-specific & ran against a predefined set of rules. Organization can impose there own rules or standards through these tools.
There are two ways to implement it,
- During Development: Integrate into developers IDE tools. It will give developers suggestions then and their itself. This will avoid any possible coding errors to be detected in later stages.
- During Build:- You can make this a standard gate practice during your dev or test build cycle. If it has a certain high level of vulnerabilities then it needs to have an approval process for promotion in case of manual override.
I have seen first one is very much effective. It is painless & gives immediate feedback on your code like code coverage, coding standards, duplication of code are flagged.
SCA (Software Composition Analysis) :- SCA tools are not necessarily AST but take one more extra step to analyze the binaries which is another important step besides scanning your static proprietary code. Nowadays open source binaries we all use and that needs to be scanned before we start using them. Generally, these are not detected by your SAST tool. They don’t run against your codebase they run against your digital signatures of binary libraries. They identify known vulnerabilities against your binary libraries.
DAST(Dynamic Application Security Testing) :- DAST is mostly running onto running an application that doesn’t do SAST level testing. It catches most of the false positives in SAST. It is application code-independent. It doesn’t have code visibility so it won’t be able to point about where the issue is in code, so it needs some degree of expert knowledge for any resolution. This makes it difficult to be embedded in the DevOps cycle, it is a bit of manual resolution since DAST can’t identify vulnerable lines of code. One of the example of DAST identification of SQL Injection detection,
IAST(Interactive Application Security Testing) :- It is more sophisticated than DAST. It provides you more insight than what DAST can detect. A security agent will be installed on your application system & it will continue to identify the vulnerabilities in a running application & it provides contextual help to the developer for resolution. The major benefit is, it can be deployed in the early lifecycle. Selection of IAST tool needs to be made carefully to the platform you use & language.
Conclusion: For successful coverage of the security aspect of DevSecOps. You need to enable your development group with appropriate security testing tools & inject them into your CI/CD platform. That is the ultimate recipe for a successful DevSecOps. There are a lot of tools available in the market a careful study needs to be made before you make any purchase & implement it anything in your environment. A proper architectural landscape needs to be painted across the organization before any such implementation to be done. In certain scenarios maybe multiple tools are used for different purpose. Cost also plays an important role in decision making because every tool is purpose-built & we can pick and choose based on the type of application it is and what kind of data it is serving. As more and more organizations started to move into cloud infrastructure became programmable & quickly these tools need to be implemented at infrastructure code.