---
type: pesquisa
title: "BairesDev AppSec — testing and verification stack"
description: "SAST, DAST, IAST, SCA, secret scanning and AI-code verification in BairesDev's public model."
tags: [bairesdev, sast, dast, iast, sca, testing, verification]
timestamp: "2026-07-20T18:30:00-03:00"
---

# Testing and verification stack

## Static analysis — SAST

SAST examines source or intermediate code early. It is strong for repeatable patterns, insecure APIs and coding defects, but weak when runtime configuration, authorization state, business logic or deployment context determines exploitability. BairesDev's model places SAST in CI and expects developers to receive rapid feedback.

## Dynamic analysis — DAST

DAST tests a running application and can expose externally observable behavior, configuration problems and attack paths that static analysis cannot see. It needs representative environments, authentication coverage and careful triage to avoid confusing reachability with exploitability.

## Interactive analysis — IAST

IAST combines runtime observation with code context. It can improve signal and localization, but depends on test-path coverage and instrumentation. It complements rather than replaces SAST, DAST and manual testing.

## Software composition analysis — SCA

SCA inventories open-source dependencies, vulnerabilities and licenses. BairesDev explicitly connects SCA with visibility, risk management and license compliance. Modern practice also requires registry validation, lockfile review, transitive dependency awareness and SBOM evidence.

## Secret scanning

The secure-SDLC article names secret scanning as a default automated check. Treat it as prevention plus response: block new secrets, revoke exposed credentials, search history and verify that replacement credentials are not also exposed.

## AI-generated code verification

The [AI coding best-practices article](https://www.bairesdev.com/blog/ai-coding-best-practices/) extends the stack: unit and integration tests before merge, static analysis and linting, build gates, SAST/SCA for all generated code, and dependency validation against real registries. The principle is simple: provenance does not reduce the verification requirement.

## Coverage matrix

| Question | Best control |
|---|---|
| Is the code pattern unsafe? | SAST |
| Is the running app exploitable? | DAST |
| Which code path caused runtime behavior? | IAST |
| Is a dependency vulnerable or non-compliant? | SCA/SBOM |
| Did a credential enter source or history? | secret scanning |
| Does the system withstand adversarial reasoning? | manual review/pentest/red team |

## Cross-links

Use this page with [Secure SDLC control plane](secure-sdlc.md) and [Threat modeling, supply chain and cloud](threat-modeling-supply-chain.md).