We covered several acronyms common in application security in a previous post: SAST, DAST, and SCA. We’ll continue our discussion on AppSec concepts today by focusing on IAST, IaC, and secrets.
Interactive application security testing (IAST)
Interactive application security testing (IAST) is a fairly involved process. The tester looks for security issues while running the application simultaneously. The tester finds and reports on vulnerabilities as they’re found, so while the use of IAST doesn’t add time to your CI/CD pipeline, it does require an extra step in your software development life cycle (SDLC).
The upside to IAST options is that they can be deployed to your QA/testing environment and run alongside any functional tests you’re doing (IAST tools are an especially good fit for API tests).
The downside is that the only security issues that IAST tools can identify are those in areas exercised by the functional tests — if you have areas of missing code coverage, you won’t find security issues there either.
Infrastructure-as-Code (IaC) Security
If you’re not familiar with infrastructure-as-code (IaC), IaC is the practice of using definition files to manage and provision your application’s infrastructure. Deploying and managing infrastructure used to be a fairly manual process, but IaC has helped minimize the work required of IT teams while also producing more stable environments.
Because of its *-as-code paradigm, you can treat IaC configurations the way you would any other piece of software. Not only can you version control your configurations, you can test them the way you would any piece of code that you want merged into the main branch. This includes security testing.
It’s possible to use runtime tests to identify issues with how the environment is built, but you can also shift left by integrating SAST tools into your CI/CD pipeline to look for the same security issues (such as misconfigurations in how you’re building your cloud-based resources, policy violations, and so on) when it costs less time and money to fix.
Secrets are digital authentication credentials such as:
- API keys and tokens
- Database credentials
- Encryption keys (e.g., PGP keys)
- SSH keys
- SSL/TLS certificates
Secrets typically guard elevated privileges (as you can see from the above, they can guard some mission-sensitive aspects of an application); they require more intense security-related controls than offered by traditional password management practices — and yet, they’re commonly mismanaged and easily uncovered by those with the determination to do so.
Modern software development architectures, such as microservice- or API-centric ones, require developers to exchange credentials programmatically quite frequently. As such, it’s common to find these hard-coded and shared inadvertently. Furthermore, such credentials may become “buried” — as applications get bigger and bigger, it can become difficult (without external tools to help) to find instances where such hard-coding occurs.
This article covered several AppSec concepts that you should be aware of: security for IAST, security for IaC, and secrets. If you haven’t already, see also our earlier post on different types of testing tools; SAST, DAST, and SCA.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog – Medium authored by Katie Horne. Read the original post at: https://blog.shiftleft.io/iast-iac-secrets-a-guide-to-app-sec-tools-4fb68686f78d?source=rss—-86a4f941c7da—4