Subcapability 01 de 04 · Security Engineering

Shift-Left Security

SAST, DAST e SCA integrados ao pipeline de CI que reduzem custo de correção por ordem de magnitude e eliminam o pentest anual como única linha de defesa.

O que está em jogo

A vulnerabilidade que aparece no relatório de incidente existia há meses no código. O pentest a descobriu tarde, com usuários já expostos, custo de remediação máximo e notificação regulatória obrigatória. Cada fase que passa sem controle automatizado multiplica o custo de cada vulnerabilidade que escapa.

O que é, na prática

O custo de corrigir uma vulnerabilidade cresce por ordem de magnitude a cada fase do ciclo de desenvolvimento. No design, custa uma conversa. No código, custa um pull request. Em staging, custa um ciclo de teste. Em produção, custa incidente com usuário afetado, notificação regulatória e remediação emergencial. A decisão de quando integrar segurança é uma decisão econômica, e cada empresa que trata pentest anual como única validação paga esse custo de forma concentrada e com máximo impacto.

Como atuamos

Ganhos mensuráveis

O que muda no resultado quando essa subcapacidade amadurece.

Perguntas frequentes

O que é SAST e como difere de um pentest?

SAST, análise estática de código, inspeciona o código-fonte sem executar a aplicação, capturando padrões de vulnerabilidade conhecidos como injeção SQL, XSS e problemas de autenticação no momento do pull request. Pentest é uma avaliação manual de segurança conduzida por especialista em um ponto no tempo. A diferença operacional é a frequência: SAST roda em cada commit, pentest acontece anualmente ou semestralmente. Usados juntos, SAST detecta o que é automatizável, pentest encontra o que exige raciocínio adversarial que ainda não é automatizável.

O que é SCA e por que dependências são um risco crescente?

SCA, análise de composição de software, avalia as dependências de terceiros do projeto por vulnerabilidades conhecidas em bases como o National Vulnerability Database. Aplicações modernas têm 70% a 90% do código proveniente de bibliotecas externas. Cada nova vulnerabilidade publicada em uma biblioteca amplamente usada, como o evento Log4Shell, afeta simultaneamente todos os projetos que a usam. SCA automatizado detecta e alerta sobre essas exposições antes que virem incidente.

O que é SBOM e quando se torna obrigatório?

SBOM, Software Bill of Materials, é o inventário completo de componentes, dependências e suas versões que compõem um software. Em sistemas críticos e em fornecedores de software para o governo federal dos EUA, SBOM passou a ser requisito regulatório a partir de 2021. Para empresas em setores regulados ou que fornecem para grandes clientes corporativos, o SBOM é o documento que permite resposta rápida quando uma nova vulnerabilidade afeta a cadeia de suprimentos de software.

Shift-left não vai sobrecarregar os developers com alertas de segurança?

O risco existe quando as ferramentas são configuradas sem critério de severidade. A prática correta é configurar alertas por severidade CVSS, silenciando ruído de baixa prioridade e escalando apenas o que exige ação antes do merge. Um pipeline bem configurado alerta sobre o crítico e registra o restante para revisão periódica. O volume de alertas diminui conforme a maturidade do código aumenta.

Como priorizar vulnerabilidades quando o backlog é grande?

Por dois critérios simultâneos: severidade CVSS e exposição real no ambiente de produção. Vulnerabilidade crítica em componente diretamente exposto à internet tem prioridade máxima. Vulnerabilidade média em biblioteca usada apenas internamente pode aguardar próximo ciclo de manutenção. Ferramentas de SCA modernas já combinam CVSS com análise de acessibilidade para ajudar na priorização sem depender de julgamento individual a cada alerta.

Quer clareza sobre onde investir primeiro?

Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.