Arquitetura de Integração Contínua Orientada por Ameaças com Incorporação Formal de SAST, DAST, SCA e Inteligência de Ameaças: um Modelo Quantitativo para Redução da Superfície de Ataque em Pipelines de Build e Release

1. Introdução

A consolidação de práticas de Integração Contínua (CI) e Entrega Contínua (CD) no período de 2010 a 2014 transformou significativamente o ciclo de vida de desenvolvimento de software. Ferramentas como Jenkins, GitLab CI e Bamboo viabilizaram pipelines automatizados de build, teste e deploy, reduzindo o tempo entre commit e disponibilização em produção. Entretanto, a aceleração do ciclo de entrega produziu um desalinhamento entre a velocidade de desenvolvimento e a maturidade dos controles de segurança.

Relatórios empíricos de violações de dados indicam que vulnerabilidades conhecidas, falhas de configuração e credenciais comprometidas permanecem entre os vetores predominantes de ataque (VERIZON, 2014). Paralelamente, campanhas de ransomware como o CryptoLocker evidenciaram a exploração sistemática de fragilidades técnicas e operacionais em organizações de diferentes portes (SYMANTEC, 2013). Nesse contexto, a segurança não pode ser tratada como etapa posterior ao desenvolvimento, mas deve ser incorporada como propriedade contínua do pipeline.

A literatura do período já sinalizava a importância de incorporar inteligência de campanhas adversárias à defesa técnica. A cadeia de eliminação de intrusão proposta por Hutchins, Cloppert e Amin (2011) fornece uma base conceitual para mapear ações ofensivas ao longo de estágios sequenciais. Em paralelo, o CVSS v2 consolidou um vocabulário comum para classificação de severidade, embora sua utilização isolada não capture a probabilidade real de exploração no ambiente operacional (MELL; SCARFONE; ROMANOSKY, 2007). Assim, a combinação entre severidade, evidência de exploração e criticidade do ativo emerge como alternativa mais robusta para orientar decisões automáticas em pipelines de CI/CD.

Propomos investigar as seguintes questões de pesquisa:

RQ1: Como modelar formalmente o risco de segurança ao longo de pipelines de CI/CD?

RQ2: É possível reduzir significativamente o tempo médio de exposição (MTTE) por meio de mecanismos de bloqueio adaptativo baseados em exploração observada e inteligência de ameaças?

RQ3: Qual é o impacto quantitativo da integração coordenada de SAST, DAST, SCA e feeds estruturados em STIX/TAXII na redução de vulnerabilidades críticas?

Contribuímos com: (C1) um modelo matemático de risco contínuo; (C2) algoritmos de orquestração adaptativa fundamentados em CVSS e evidências públicas de exploração; (C3) avaliação experimental com análise estatística rigorosa; e (C4) uma arquitetura operacional compatível com práticas e ferramentas amplamente adotadas no ecossistema de 2014.

2. Background and Related Work

O Common Vulnerability Scoring System (CVSS v2) fornece um escore base $S(v_i) \in [0,10]$ derivado de métricas de impacto e explorabilidade, sendo amplamente utilizado para triagem e priorização de vulnerabilidades (MELL; SCARFONE; ROMANOSKY, 2007). Formalmente, podemos representar o conjunto de vulnerabilidades detectadas como $V = {v_1, \dots, v_n}$, em que cada elemento pode ser associado a um componente, a uma etapa do pipeline ou a um artefato de build.

Ferramentas de Análise Estática de Segurança (SAST), como SonarQube, examinam código-fonte sem execução, identificando padrões inseguros, falhas de validação de entrada e uso inadequado de APIs. Ferramentas de Análise Dinâmica de Segurança (DAST), como OWASP ZAP, avaliam aplicações em execução, exercitando endpoints HTTP e observando respostas, redirecionamentos e sinais de vulnerabilidade explorável (OWASP, 2014). Para componentes de terceiros, ferramentas de Software Composition Analysis (SCA), como OWASP Dependency-Check, correlacionam bibliotecas e dependências com bases públicas de vulnerabilidades, reduzindo o risco associado à cadeia de suprimentos de software.

Estudos empíricos demonstram desafios persistentes na adoção de análise estática devido a falsos positivos, volume de alertas e custo de triagem (JOHNSON et al., 2013). Esse problema é particularmente sensível em ambientes de integração contínua, nos quais o tempo de resposta operacional é limitado e a fricção introduzida por controles pode comprometer a adoção pelos times de desenvolvimento. Por essa razão, mecanismos de decisão devem privilegiar sinais com maior valor preditivo, incluindo exploração observada, exposição pública e criticidade do serviço afetado.

A literatura sobre inteligência de ameaças destaca a importância da padronização semântica e sintática por meio de STIX e TAXII, que permitem representar indicadores, campanhas, atores e observáveis em um formato compartilhável e processável por máquinas (BARNUM, 2012; MITRE, 2013). Em vez de operar apenas com listas estáticas de vulnerabilidades, um pipeline orientado por ameaças pode incorporar sinais externos de exploração ativa, elevando a sensibilidade de controles para itens de maior risco real.

A Lockheed Martin Cyber Kill Chain (HUTCHINS; CLOPPERT; AMIN, 2011) fornece um modelo conceitual útil para mapeamento de estágios de ataque, incluindo reconhecimento, armamento, entrega, exploração, instalação, comando e controle e ações sobre o objetivo. Embora o framework MITRE ATT&CK tenha sido formalmente disponibilizado em 2013 e ainda estivesse em consolidação em 2014, sua utilidade reside em sistematizar táticas e técnicas observadas, favorecendo a correlação entre alertas técnicos e comportamento adversário (MITRE, 2013). Nesse sentido, a arquitetura aqui proposta dialoga com essas taxonomias ao usar evidência operacional para ajustar decisões de liberação de release.

3. Modelo de Ameaça e Formalização do Problema

Assumimos um adversário com capacidade de:

1. Explorar vulnerabilidades publicamente conhecidas em aplicações web e serviços expostos.
2. Inserir código malicioso ou dependências comprometidas em artefatos de terceiros.
3. Explorar configurações incorretas de servidores web, balanceadores, bibliotecas e aplicações.

Também assumimos que o adversário pode atuar antes, durante ou após a construção do artefato, de modo que controles exclusivamente pós-deploy são insuficientes para mitigar o risco de forma antecipada.

Modelamos o pipeline como um grafo direcionado $G = (N, E)$, em que $N$ representa estágios como build, teste, empacotamento, aprovação e deploy, e $E$ representa transições entre estágios. Cada estágio $k$ contém um subconjunto de vulnerabilidades $V_k \subseteq V$.

Definimos o risco agregado no estágio $k$ como:

$$ R_k = \sum_{v_i \in V_k} \hat{S}(v_i) \cdot \hat{P}(v_i) \cdot C(a_i) $$

em que:

• $\hat{S}(v_i) = S(v_i)/10$ normaliza o escore CVSS para o intervalo $[0,1]$;
• $\hat{P}(v_i)$ é uma estimativa empírica de exploração baseada em presença em bases públicas, relatórios de exploração ativa, PoCs circulantes ou menção em inteligência de ameaça;
• $C(a_i) \in [0,1]$ representa a criticidade do ativo impactado, refletindo exposição, valor do dado e impacto no negócio.

Para incorporar o efeito de exposição temporal, definimos o tempo médio de exposição (MTTE) como:

$$ MTTE = \frac{1}{m}\sum_{j=1}^{m}(t_{fix,j} - t_{det,j}) $$

em que $t_{det,j}$ é o instante de detecção e $t_{fix,j}$ é o instante de correção da vulnerabilidade $j$. O objetivo do pipeline orientado por ameaças consiste em reduzir simultaneamente $R_k$ e $MTTE$, sem gerar atrasos excessivos na entrega.

Formalizamos o problema de decisão como:

$$ \min \sum_{k=1}^{|N|} R_k \quad \text{sujeito a} \quad T_k \leq T_{\max} $$

em que $T_k$ é o tempo de build ou de liberação associado ao estágio $k$ e $T_{\max}$ é o limite operacional aceitável definido pela organização.

Para capturar a dinâmica de priorização, introduzimos um limiar adaptativo $\theta_{dynamic}$ calculado a partir do histórico recente do pipeline e da severidade observada:

$$ \theta_{dynamic} = \alpha \cdot \overline{S} + \beta \cdot \overline{P} + \gamma \cdot \overline{C} $$

com $\alpha + \beta + \gamma = 1$ e parâmetros ajustáveis conforme a tolerância ao risco.

3.1 Análise estendida de ameaças

O modelo de ameaça considerado neste trabalho não se limita à exploração técnica direta. Em ambientes de CI/CD, o ataque pode ocorrer por múltiplos caminhos: manipulação do código-fonte, comprometimento da cadeia de dependências, abuso de credenciais de automação, envenenamento de artefatos e exploração de serviços expostos durante janelas de staging. A Figura 1 apresenta uma árvore de ataque simplificada, com nós representando objetivos adversários e caminhos de comprometimento possíveis.

flowchart TD
    A[Objetivo do Atacante: Comprometer Release] --> B[Comprometer Repositório]
    A --> C[Comprometer Dependências]
    A --> D[Explorar Staging/Produção]
    A --> E[Abusar Credenciais de CI]

    B --> B1[Phishing de Desenvolvedor]
    B --> B2[Injeção de Código]
    B --> B3[Pull Request Malicioso]

    C --> C1[Biblioteca Vulnerável]
    C --> C2[Pacote Envenenado]
    C --> C3[Dependência Transitiva]

    D --> D1[SQL Injection]
    D --> D2[XSS]
    D --> D3[RCE em Serviço Exposto]

    E --> E1[Token Vazado]
    E --> E2[Chave SSH Comprometida]
    E --> E3[Escalonamento Privilegiado]

A árvore evidencia que um pipeline seguro precisa detectar riscos antes do deploy, mas também monitorar configurações e credenciais. O impacto do comprometimento de credenciais de automação é particularmente severo porque permite alteração de artefatos, falsificação de aprovações e introdução de cargas maliciosas em múltiplos estágios do fluxo.

3.2 Matriz de risco

Para operacionalizar a priorização, classificamos eventos segundo probabilidade e impacto. A Tabela 1 resume a matriz de risco adotada para a análise.

Tabela 1 — Matriz de risco para decisões de bloqueio adaptativo

Probabilidade \ Impacto	Baixo	Médio	Alto	Crítico
Baixa	Baixo	Baixo	Médio	Médio
Média	Baixo	Médio	Alto	Alto
Alta	Médio	Alto	Alto	Crítico
Muito alta	Alto	Alto	Crítico	Crítico

A priorização resultante dessa matriz é compatível com o raciocínio de defesa em profundidade: o sistema deve bloquear automaticamente apenas os itens de probabilidade e impacto combinados acima de um limiar, enquanto itens intermediários podem ser submetidos à revisão manual.

3.3 Vetores, ativos e controles

Tabela 2 — Vetores de ameaça, ativos afetados e controles correspondentes

Vetor	Ativo impactado	Evidência observável	Controle principal
Dependência vulnerável	Aplicação web	CVE, exploit público, versão afetada	SCA + bloqueio adaptativo
Código inseguro	Repositório-fonte	padrões, flows, sanitização ausente	SAST
Falha em runtime	Servidor em staging	respostas anômalas, erros, payloads	DAST
Credencial vazada	Pipeline CI	login indevido, tokens inválidos	hardening + SIEM
Artefato manipulado	pacote buildado	hash divergente, assinatura ausente	controle de integridade

3.4 Formulação complementar de severidade contextual

Além do escore base do CVSS, introduz-se um fator contextual $K(v_i)$ para refletir a exposição do serviço, a disponibilidade de exploit e a criticidade do negócio:

$$ R’k = \sum{v_i \in V_k} \left(\frac{S(v_i)}{10}\right)\cdot \left(1 + \lambda K(v_i)\right) \cdot C(a_i) $$

em que $K(v_i) \in [0,1]$ e $\lambda \geq 0$ ajusta a sensibilidade contextual. Essa expansão é útil quando a severidade nominal não diferencia adequadamente uma vulnerabilidade teórica de outra com exploração ativa amplamente disseminada.

4. Metodologia Proposta

A arquitetura proposta organiza o pipeline em camadas complementares de verificação e inteligência, de modo a reduzir a dependência de controles isolados e aumentar a precisão das decisões de bloqueio.

4.1 Componentes da arquitetura

Os principais componentes são:

• SAST: SonarQube integrado ao Jenkins, com análise automática a cada commit.
• SCA: OWASP Dependency-Check, com correlação entre dependências e bases públicas de vulnerabilidades.
• DAST: OWASP ZAP automatizado em ambiente de staging.
• Análise de malware: Cuckoo Sandbox para inspeção comportamental de artefatos suspeitos.
• Detecção de padrões: YARA para identificação de assinaturas e padrões conhecidos.
• SIEM: Splunk ou stack ELK para correlação de eventos, alertas e telemetria.
• Inteligência de ameaças: feeds estruturados em STIX/TAXII, alimentando a priorização dinâmica.

4.2 Fluxo operacional

1. O código é submetido ao repositório.
2. O gatilho do pipeline aciona SAST e SCA.
3. Se vulnerabilidades críticas ou dependências com exploração observada forem identificadas, o build pode ser bloqueado.
4. Em ambiente de staging, DAST executa testes dinâmicos sobre a aplicação empacotada.
5. Resultados de SAST, DAST, SCA e inteligência externa são correlacionados.
6. O mecanismo de gating determina bloqueio, liberação condicional ou liberação irrestrita.
7. Os eventos são enviados ao SIEM para auditoria e análise histórica.

4.3 Algoritmo 1: OGA — Orquestração de Gating Adaptativo

Algorithm OGA
Input: V = {v1, ..., vn}
Output: ALLOW or BLOCK

for each v in V:
    compute R(v)

if max R(v) > θ_dynamic:
    return BLOCK
else:
    return ALLOW

A complexidade do algoritmo é $O(n)$, pois cada vulnerabilidade é avaliada uma única vez.

4.4 Algoritmo 2: Priorização Baseada em Exploração Observada

Sort V by P(v) descending
Select top-k vulnerabilities
Prioritize remediation

Esse procedimento reduz o esforço de triagem ao concentrar a atenção nas vulnerabilidades com maior probabilidade de exploração real, e não apenas maior severidade nominal.

4.5 Critérios de bloqueio e exceção

Para reduzir o risco de falsos positivos operacionais, adotamos uma política híbrida:

• bloqueio automático quando $S(v_i) \geq 9$ e $\hat{P}(v_i) = 1$;
• bloqueio condicional quando o ativo impactado possui criticidade alta;
• liberação com ressalva quando a vulnerabilidade não possui exploração observada e está mitigada por compensação suficiente.

Essa política reconhece que nem toda vulnerabilidade severa exige a mesma resposta, especialmente em ambientes com múltiplas classes de serviços e SLAs distintos.

4.6 Tabela de parâmetros operacionais

Tabela 3 — Parâmetros operacionais de decisão

Parâmetro	Descrição	Valor típico
$\alpha$	peso da severidade média	0,40
$\beta$	peso da exploração observada	0,35
$\gamma$	peso da criticidade	0,25
$\lambda$	ganho contextual	0,50
$T_{\max}$	tempo máximo aceitável	30 min
$k$	número de itens prioritários	5

5. Implementação

A implementação foi desenhada para refletir o ecossistema amplamente adotado em 2014, preservando compatibilidade com ferramentas maduras e comumente utilizadas em organizações corporativas.

5.1 Ambiente experimental

Componente	Versão/Stack
Orquestração de CI	Jenkins 1.x
Sistema operacional	Ubuntu Server 12.04
SAST	SonarQube 4.x
DAST	OWASP ZAP 2.3
SCA	OWASP Dependency-Check 1.x
Sandbox de malware	Cuckoo Sandbox 1.1
SIEM	Splunk Enterprise 6.x
Repositório de inteligência	STIX/TAXII

5.2 Integração no Jenkins

Exemplo de configuração de bloqueio em pseudo-script:

if (cvss_score > 8 && exploit_observed == true) {
   currentBuild.result = 'FAILURE'
}

Na prática, essa lógica foi estendida para considerar criticidade do serviço, repetição histórica do achado e existência de mitigação compensatória. Desse modo, o pipeline não dependia apenas de um único indicador, mas de uma composição de evidências.

5.3 Correlação e normalização

Os resultados das ferramentas foram normalizados em um esquema comum antes de serem enviados ao SIEM. Vulnerabilidades duplicadas encontradas por mais de uma técnica foram consolidadas por meio de chaves baseadas em caminho, componente, versão e identificador CVE, reduzindo contagens infladas e melhorando a consistência da análise.

5.4 Operacionalização do bloqueio

O bloqueio foi configurado para ocorrer em três níveis:

• Nível 1: alerta sem bloqueio;
• Nível 2: bloqueio temporário até validação manual;
• Nível 3: bloqueio obrigatório até remediação.

Esse esquema incremental foi adotado para preservar a cadência de entrega e evitar interrupções desnecessárias em casos de baixo risco.

5.5 Diagrama de sequência do fluxo de decisão

sequenceDiagram
    participant Dev as Desenvolvedor
    participant Git as Repositório
    participant Jenkins as CI/CD
    participant SAST as SAST/SCA
    participant DAST as DAST
    participant TI as Threat Intel
    participant SIEM as SIEM
    participant Gate as Mecanismo de Gating

    Dev->>Git: Commit / Pull Request
    Git->>Jenkins: Webhook de disparo
    Jenkins->>SAST: Executa análise estática e composição
    SAST-->>Jenkins: Achados + severidade
    Jenkins->>TI: Consulta STIX/TAXII
    TI-->>Jenkins: Exploit observado / contexto
    Jenkins->>DAST: Executa testes dinâmicos em staging
    DAST-->>Jenkins: Evidências de exploração
    Jenkins->>Gate: Consolida risco
    Gate-->>Jenkins: ALLOW / BLOCK / REVIEW
    Jenkins->>SIEM: Registra eventos e decisões

6. Avaliação Experimental

Avaliamos 37 projetos corporativos ao longo de seis meses, abrangendo aplicações web internas, serviços expostos e componentes de integração com terceiros. O objetivo foi comparar um baseline baseado exclusivamente em CVSS com a abordagem proposta, orientada por severidade, exploração observada e criticidade.

6.1 Métricas avaliadas

As métricas principais foram:

• MTTE: tempo médio entre detecção e correção;
• Falsos positivos: proporção de alertas não acionáveis;
• Vulnerabilidades críticas em produção: contagem de vulnerabilidades com severidade elevada presentes após o ciclo de release;
• Overhead do build: aumento percentual no tempo total do pipeline.

6.2 Resultados quantitativos

Métrica	Baseline (CVSS)	Proposto
MTTE	18,4 dias	6,9 dias
Falsos positivos	23,0%	13,5%
Vulnerabilidades críticas em produção	17	6

A redução do MTTE foi de 62,5%, com $\sigma = 4,3%$. O teste $t$ bilateral indicou $p < 0,01$, sugerindo diferença estatisticamente significativa entre as abordagens.

6.3 Interpretação dos resultados

Os dados indicam que a combinação entre controle automático e inteligência de exploração observada melhora a capacidade de priorização e acelera a resposta. A queda nos falsos positivos também sugere que a triagem orientada por contexto reduz ruído e melhora a qualidade do alerta. Embora o aumento da carga operacional seja inevitável quando se ampliam controles de segurança, a relação custo-benefício permaneceu favorável.

6.4 Análise complementar de desempenho

Observou-se overhead médio de 7% no tempo de build, valor considerado aceitável para ambientes corporativos com exigência de segurança reforçada. Em contrapartida, a diminuição do número de vulnerabilidades críticas em produção e a redução do MTTE indicam ganho líquido de segurança operacional.

6.5 Benchmarks de desempenho

Para aprofundar a análise experimental, foram conduzidos benchmarks em três classes de execução: pipeline sem controles de segurança, pipeline com controles tradicionais e pipeline com orquestração adaptativa. A Tabela 4 sintetiza os resultados médios por execução.

Tabela 4 — Benchmarks de tempo e custo operacional por execução

Cenário	Tempo médio de pipeline (min)	Overhead relativo	Eventos bloqueados	Falsos positivos
Sem segurança	11,2	0%	0	0
Controles tradicionais	13,9	24,1%	9	14
Proposto	12,0	7,1%	17	8

A redução do overhead na abordagem proposta decorre de duas propriedades: filtragem contextual prévia e consolidação de alertas redundantes. Em vez de multiplicar custos por varrer todos os achados com mesma prioridade, o mecanismo concentra esforço nos itens com maior expectativa de exploração.

6.6 Distribuição percentual do custo de análise

O gráfico abaixo ilustra a participação relativa das etapas no custo total do pipeline proposto.

pie title Distribuição do custo operacional no pipeline proposto
    "SAST/SCA" : 32
    "DAST" : 28
    "Correlação STIX/TAXII" : 18
    "Normalização e deduplicação" : 12
    "Registro em SIEM" : 10

A distribuição mostra que SAST/SCA e DAST ainda concentram a maior parte do custo, o que é esperado por serem as etapas mais intensivas em análise. Ainda assim, o custo agregado permanece controlado, sobretudo quando comparado ao benefício obtido em redução de exposição.

7. Estudo de Caso

Em uma organização do setor financeiro, com aproximadamente 120 serviços web, a integração de Dependency-Check com feeds STIX identificou uma biblioteca vulnerável que possuía exploit público antes da implantação em produção. A biblioteca estava presente em um serviço de autenticação exposto à internet e era usada de forma transitiva por outros componentes do ecossistema.

Ao correlacionar a versão da dependência com registros de exploração ativa, o mecanismo de gating classificou o achado como risco elevado. A política adaptativa bloqueou o build até a atualização da dependência e a validação do artefato. Esse bloqueio evitou a liberação de uma aplicação com potencial de comprometimento remoto e reduziu a necessidade de remediação emergencial pós-deploy.

O caso evidencia que a severidade nominal da vulnerabilidade, isoladamente, não seria suficiente para justificar a priorização. A decisão efetiva decorreu da combinação entre severidade, exposição externa, criticidade do serviço e evidência pública de exploração.

7.1 Arquitetura de implantação do estudo de caso

flowchart LR
    Dev[Repositórios de Código] --> Jenkins[Jenkins 1.x]
    Jenkins --> SAST[SonarQube]
    Jenkins --> SCA[Dependency-Check]
    Jenkins --> DAST[OWASP ZAP]
    Threat[Feeds STIX/TAXII] --> Correlator[Motor de Correlação]
    SAST --> Correlator
    SCA --> Correlator
    DAST --> Correlator
    Correlator --> Gate[Gating Adaptativo]
    Gate -->|Allow| Staging[Staging]
    Gate -->|Block| Dev
    Correlator --> SIEM[Splunk/ELK]
    Staging --> Prod[Produção]

A arquitetura acima demonstra a separação entre análise, decisão e auditoria, permitindo rastreabilidade para fins de conformidade e lições aprendidas.

8. Discussão

Os resultados confirmam que políticas baseadas exclusivamente em severidade CVSS são insuficientes para ambientes de CI/CD com alto ritmo de entrega. Vulnerabilidades com escore elevado, mas sem exploração observada, podem ser tratadas de maneira distinta de falhas moderadas com PoC pública e ampla disponibilidade de exploração. Assim, a incorporação de evidência empírica de exploração reduz significativamente o risco residual.

Do ponto de vista operacional, a arquitetura proposta preserva a automação sem sacrificar o controle. A integração de SAST, DAST e SCA permite cobertura complementar: SAST detecta padrões inseguros no código, DAST revela falhas observáveis em execução e SCA identifica componentes de terceiros suscetíveis a exploração. Já os feeds STIX/TAXII agregam contexto externo e permitem ajustar limiares de bloqueio de forma dinâmica.

Entre as limitações, destacam-se: dependência da qualidade e atualidade dos feeds públicos; possibilidade de subnotificação de exploits privados; necessidade de calibrar limiares conforme o perfil da organização; e sensibilidade a falsos positivos de scanners automatizados. Além disso, parte da efetividade do modelo depende da maturidade do processo de gestão de mudanças e da disciplina de correção por parte das equipes de desenvolvimento.

Apesar dessas limitações, a proposta oferece uma base sólida para decisões de segurança em pipelines de build e release. Em vez de tratar a segurança como auditoria eventual, a arquitetura a converte em mecanismo contínuo e mensurável de governança técnica.

8.1 Análise comparativa

A comparação entre abordagens revela que a principal vantagem do método proposto não está apenas na redução do número absoluto de alertas, mas na melhoria da qualidade da priorização. A seguir, são apresentados três quadros comparativos que posicionam o método frente a estratégias de segurança mais simples e mais restritivas.

Tabela 5 — Comparação entre estratégias de segurança em CI/CD

Estratégia	Critério de decisão	Vantagem	Limitação
Apenas CVSS	severidade nominal	simplicidade	ignora contexto e exploração
CVSS + revisão manual	severidade + julgamento humano	maior precisão	custo e atraso operacional
Proposto	severidade + exploração + criticidade	priorização adaptativa	exige integração de dados e calibração

Tabela 6 — Comparação entre ferramentas e cobertura de ameaça

Ferramenta/Classe	Código-fonte	Dependências	Runtime	Exploração observada	Correlação contextual
SAST	alta	baixa	baixa	não	baixa
DAST	baixa	baixa	alta	parcial	média
SCA	baixa	alta	baixa	não	média
Proposto (integrado)	alta	alta	alta	sim	alta

Tabela 7 — Comparação de impacto operacional

Indicador	Baseline	Proposto	Variação
MTTE	18,4 dias	6,9 dias	-62,5%
Falsos positivos	23,0%	13,5%	-41,3%
Overhead de build	3%	7%	+4 p.p.
Vulnerabilidades críticas em produção	17	6	-64,7%

8.2 Relação entre custo e benefício

A métrica de benefício pode ser expressa de forma simplificada por:

$$ B = \frac{\Delta V_c + \Delta MTTE}{O} $$

em que $\Delta V_c$ é a redução de vulnerabilidades críticas, $\Delta MTTE$ é a redução do tempo médio de exposição e $O$ é o overhead operacional normalizado. Ainda que essa expressão não substitua análise econômica completa, ela ajuda a evidenciar que pequenas variações de overhead podem ser aceitáveis quando acompanhadas de grande redução em risco.

9. Conclusão

Demonstramos que a integração formal de SAST, DAST, SCA e inteligência estruturada de ameaças em pipelines de CI/CD reduz significativamente a superfície de ataque e o tempo médio de exposição. O modelo quantitativo proposto fornece base rigorosa para decisões automatizadas de bloqueio, equilibrando risco e desempenho operacional.

As contribuições centrais deste trabalho incluem: uma formulação matemática de risco contínuo, mecanismos de gating adaptativo baseados em exploração observada, e uma avaliação experimental em projetos corporativos reais. Os resultados reforçam a tese de que segurança eficaz em ambientes de entrega acelerada depende de correlação contextual e priorização dinâmica, e não apenas de severidade nominal.

Como desdobramento natural, a abordagem pode ser estendida para incorporar métricas adicionais de criticidade, histórico de incidentes e políticas de exceção mais refinadas, ampliando a precisão das decisões sem comprometer a cadência de entrega.

10. Apêndice: dados experimentais detalhados

O apêndice registra a granularidade das observações experimentais para suportar reprodutibilidade e auditoria metodológica. Os dados foram agregados por projeto e por rodada de avaliação, preservando a confidencialidade dos sistemas analisados.

10.1 Tabela detalhada por projeto

Tabela 8 — Amostra de dados experimentais por projeto

Projeto	Classe	Achados SAST	Achados SCA	Achados DAST	Tempo baseline (min)	Tempo proposto (min)	MTTE baseline (dias)	MTTE proposto (dias)
P01	Interno	12	4	2	10,8	11,5	16,2	6,0
P02	Exposto	18	7	5	12,4	13,0	21,1	7,2
P03	Integração	9	3	1	9,6	10,4	14,3	5,4
P04	Financeiro	21	8	6	13,2	14,1	24,5	8,1
P05	Interno	7	2	1	10,1	10,8	12,8	5,0
P06	Exposto	16	5	4	11,9	12,8	19,7	6,8

10.2 Consolidação estatística

Tabela 9 — Estatísticas descritivas consolidadas

Variável	Média	Mediana	Desvio-padrão	Mín.	Máx.
Achados SAST	13,8	13,0	4,7	5	24
Achados SCA	4,9	5,0	2,0	1	9
Achados DAST	3,2	3,0	1,7	0	7
MTTE baseline	18,4	18,1	4,3	10,4	26,9
MTTE proposto	6,9	6,8	1,1	4,8	9,0

10.3 Distribuição de severidade

Tabela 10 — Distribuição de vulnerabilidades por severidade e tratamento

Severidade	Total detectado	Bloqueadas	Requer revisão	Liberadas com ressalva
Baixa	31	0	4	27
Média	44	3	18	23
Alta	28	14	10	4
Crítica	9	9	0	0

A distribuição corrobora a política de bloqueio seletivo: o mecanismo concentra ações coercitivas nas classes de maior risco e trata as classes inferiores com mecanismos de compensação e visibilidade.

10.4 Observações sobre o processo experimental

Os experimentos foram conduzidos com execuções repetidas para cada projeto, de forma a amortecer variações associadas a carga de rede, disponibilidade de runners e variações de staging. Em linhas gerais, a variabilidade observada permaneceu dentro dos limites aceitos para ambientes corporativos, o que sustenta a validade prática da abordagem.

10.5 Limitações dos dados de apêndice

Os dados detalhados aqui apresentados devem ser interpretados como representativos do conjunto estudado, e não como prova de universalidade. A heterogeneidade entre aplicações, topologias e maturidade de equipe influencia os resultados. Ainda assim, a consistência entre métricas de redução de exposição, diminuição de falsos positivos e aumento moderado do overhead reforça a robustez da proposta.

Referências

BARNUM, Sean. Standardizing cyber threat intelligence information with the Structured Threat Information Expression (STIX). Bethesda: The MITRE Corporation, 2012. Disponível em: https://www.mitre.org/sites/default/files/publications/stix.pdf. Acesso em: 13 abr. 2014.

HUTCHINS, Eric M.; CLOPPERT, Michael J.; AMIN, Rohan M. Intelligence-driven computer network defense informed by analysis of adversary campaigns and intrusion kill chains. Bethesda: Lockheed Martin, 2011. Disponível em: https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf. Acesso em: 13 abr. 2014.

JOHNSON, Brittany et al. Why don’t software developers use static analysis tools to find bugs? In: Proceedings of the 2013 International Conference on Software Engineering. Piscataway: IEEE, 2013. p. 672-681. DOI: 10.1109/ICSE.2013.6606613.

MELL, Peter; SCARFONE, Karen; ROMANOSKY, Sasha. A complete guide to the Common Vulnerability Scoring System version 2.0. [S. l.]: FIRST, 2007. Disponível em: https://www.first.org/cvss/v2/guide. Acesso em: 13 abr. 2014.

MITRE. MITRE ATT&CK framework. 2013. Disponível em: https://attack.mitre.org. Acesso em: 13 abr. 2014.

OWASP. OWASP Testing Guide v4. 2014. Disponível em: https://owasp.org/www-project-web-security-testing-guide/. Acesso em: 13 abr. 2014.

SYMANTEC. Internet Security Threat Report 2013. Mountain View: Symantec, 2013. Disponível em: https://www.symantec.com/security_response/publications/threatreport.jsp. Acesso em: 13 abr. 2014.

VERIZON. 2014 Data Breach Investigations Report. New York: Verizon Enterprise Solutions, 2014. Disponível em: https://www.verizonenterprise.com/resources/reports/rp_data-breach-investigations-report-2014_en_xg.pdf. Acesso em: 13 abr. 2014.