AppSec Orientada a Evidências: Um Framework Formal e Escalável para Orquestração de Segurança de Aplicações Baseada em Modelagem de Ameaças e Análise Híbrida Contínua

1. Introduction

A segurança de aplicações (Application Security — AppSec) tornou-se um dos pilares da resiliência cibernética contemporânea. A migração para arquiteturas distribuídas, plataformas cloud‑native, APIs públicas e pipelines DevSecOps ampliou significativamente a superfície de ataque dos sistemas modernos. Relatórios empíricos demonstram que vulnerabilidades exploráveis em aplicações continuam sendo uma das principais causas de incidentes de segurança (VERIZON, 2023).

Em particular, cadeias de dependência open‑source introduzem riscos sistêmicos. O incidente associado à vulnerabilidade Log4Shell (CVE‑2021‑44228) evidenciou como uma única biblioteca amplamente utilizada pode afetar milhões de sistemas simultaneamente (MITRE, 2021). Além disso, vulnerabilidades exploradas em aplicações web continuam sendo um vetor dominante de intrusão, frequentemente associado a técnicas catalogadas na matriz MITRE ATT&CK, como T1190 (Exploit Public‑Facing Application) e T1059 (Command and Scripting Interpreter) (MITRE, 2023).

A estrutura de aplicações modernas pode ser formalizada como um grafo direcionado:

$$ G = (V, E) $$

onde $V$ representa componentes de software (serviços, bibliotecas ou APIs) e $E$ representa dependências ou fluxos de dados entre esses componentes. Em arquiteturas baseadas em microserviços, o número de arestas cresce rapidamente à medida que serviços são integrados, ampliando proporcionalmente a superfície de ataque. Enquanto a complexidade estrutural cresce aproximadamente com $O(|E|)$, muitas ferramentas de segurança analisam cada vértice isoladamente, sem considerar relações de dependência.

Ferramentas tradicionais de AppSec incluem análise estática de código (SAST), análise dinâmica (DAST) e análise de composição de software (SCA). Embora amplamente utilizadas, essas abordagens frequentemente geram resultados fragmentados e de difícil priorização operacional (ANTUNES; VIEIRA, 2010). A ausência de mecanismos formais para correlacionar evidências provenientes dessas ferramentas resulta em altos índices de falsos positivos e em dificuldade para determinar quais vulnerabilidades representam risco real.

Além disso, o crescimento recente de aplicações que incorporam modelos de inteligência artificial e APIs baseadas em grandes modelos de linguagem (LLMs) introduz novas superfícies de ataque, como prompt injection e exposição inadvertida de dados sensíveis. Embora essas ameaças não substituam vulnerabilidades clássicas, elas ampliam a necessidade de mecanismos de análise integrados e orientados a evidências (OWASP, 2023).

Diante desse cenário, formulamos as seguintes questões de pesquisa:

RQ1: Como modelar formalmente o risco de vulnerabilidades de aplicação considerando evidências heterogêneas provenientes de múltiplas fontes de análise?

RQ2: É possível reduzir falsos positivos e melhorar a priorização de vulnerabilidades sem comprometer cobertura de detecção?

RQ3: Qual o impacto operacional de uma orquestração contínua baseada em risco probabilístico no pipeline DevSecOps?

As contribuições deste trabalho são três.

Primeiro, definimos formalmente uma função de risco condicional baseada em inferência bayesiana e métricas CVSS contextualizadas.

Segundo, propomos a arquitetura EO‑AppSec, que integra resultados de SAST, DAST, SCA e telemetria operacional em um mecanismo de correlação probabilística.

Terceiro, avaliamos empiricamente o sistema em escala industrial, demonstrando melhorias quantitativas significativas na priorização de vulnerabilidades e na eficiência operacional de processos de remediação.

2. Background and Related Work

2.1 Fundamentos Formais de Avaliação de Vulnerabilidades

Formalizamos uma vulnerabilidade como uma tupla:

$$ v = (c, s, e) $$

onde $c$ representa a categoria de vulnerabilidade (por exemplo, uma classificação CWE), $s$ representa a severidade base segundo o CVSS, e $e$ representa um conjunto de evidências observáveis provenientes de ferramentas de análise ou telemetria operacional.

O risco associado à vulnerabilidade pode ser modelado como:

$$ R(v) = P(E \mid v) \cdot I(v) $$

onde $P(E \mid v)$ representa a probabilidade de exploração condicional às evidências observadas e $I(v)$ representa o impacto potencial da exploração.

Utilizando inferência bayesiana, a probabilidade posterior de exploração pode ser atualizada dinamicamente:

$$ P(v \mid E) = \frac{P(E \mid v) P(v)}{P(E)} $$

Esse modelo permite combinar múltiplas fontes de evidência, incluindo resultados de scanners, dados de runtime e histórico de exploração de vulnerabilidades.

2.2 Ferramentas e Abordagens de Detecção

As técnicas de detecção de vulnerabilidades podem ser classificadas em quatro categorias principais.

Abordagem	Características	Exemplos de Ferramentas
SAST	Análise de código-fonte sem execução	SonarQube, Coverity
DAST	Testes dinâmicos em ambiente de execução	OWASP ZAP, Burp Suite
SCA	Identificação de dependências vulneráveis	Snyk, Dependabot
Runtime/Observabilidade	Telemetria de execução e comportamento	eBPF observability, Falco

Ferramentas SAST analisam fluxos de dados e padrões de código potencialmente inseguros (CHESS; WEST, 2007). Já ferramentas DAST executam testes automatizados contra aplicações em execução para identificar vulnerabilidades exploráveis (OWASP, 2021). Ferramentas SCA identificam bibliotecas vulneráveis em cadeias de dependência open‑source.

Apesar da ampla adoção dessas tecnologias, estudos empíricos demonstram significativa variabilidade em precisão e cobertura entre ferramentas (ANTUNES; VIEIRA, 2010). Essa heterogeneidade reforça a necessidade de mecanismos de correlação entre evidências.

2.3 Segurança em Ambientes Cloud‑Native

Arquiteturas cloud‑native introduzem desafios adicionais para AppSec. Aplicações são frequentemente implantadas em clusters Kubernetes, com dependências dinâmicas e escalonamento automático. Plataformas modernas de segurança em nuvem, frequentemente classificadas como CNAPP (Cloud‑Native Application Protection Platform), buscam integrar segurança de infraestrutura, workloads e aplicações (SCARFONE; PADGETT, 2022).

Além disso, tecnologias de observabilidade baseadas em eBPF permitem coletar telemetria de baixo nível diretamente do kernel Linux, possibilitando detecção comportamental mais precisa de atividades anômalas (HÖGSTRÖM, 2023).

2.4 Limitações das Abordagens Existentes

A literatura identifica três limitações principais nos sistemas de AppSec contemporâneos.

Primeiro, a ausência de modelos probabilísticos unificados para integração de evidências provenientes de diferentes ferramentas.

Segundo, a elevada taxa de falsos positivos, que pode ultrapassar 60% em ambientes industriais (JOHNSON et al., 2013).

Terceiro, a falta de priorização baseada em probabilidade real de exploração, o que frequentemente resulta em alocação ineficiente de recursos de remediação.

3. Threat Model and Problem Formalization

Assumimos um adversário com as seguintes capacidades:

• exploração de vulnerabilidades publicamente conhecidas (CVE)
• varredura automatizada de aplicações expostas
• exploração de serviços web e APIs públicas
• execução de técnicas catalogadas na matriz ATT&CK, como T1190, T1059 e T1071

Não assumimos comprometimento inicial de usuários internos nem acesso privilegiado prévio.

Dado um conjunto de vulnerabilidades:

$$ V = {v_1, v_2, …, v_n} $$

nosso objetivo é selecionar um subconjunto ótimo $V^$ de vulnerabilidades a serem priorizadas para correção:

$$ V^ = \arg\max_{S \subseteq V} \sum_{v \in S} R(v) $$

sujeito a uma restrição orçamentária:

$$ C(S) \le B $$

onde $C(S)$ representa o custo de remediação das vulnerabilidades selecionadas e $B$ representa o orçamento disponível.

Esse problema é equivalente a uma variante do problema clássico de otimização knapsack 0‑1.

Critérios de segurança incluem:

• minimização do risco residual
• preservação de cobertura mínima de detecção $\gamma$
• maximização da redução de superfície de ataque

4. Proposed Methodology

4.1 Arquitetura EO‑AppSec

A arquitetura proposta integra múltiplos componentes.

Componente	Função
Coletor de Evidências	Consolida resultados de scanners e telemetria
Motor de Correlação	Normaliza e correlaciona evidências
Módulo Bayesiano	Estima probabilidade de exploração
Orquestrador DevSecOps	Integra análise ao pipeline CI/CD

O fluxo operacional inicia com a execução de ferramentas de análise durante o pipeline CI/CD. Os resultados são agregados pelo coletor de evidências e normalizados em um esquema comum baseado em CVE e CWE. O módulo bayesiano então calcula probabilidades condicionais de exploração.

4.2 Algoritmo 1 — Agregação de Evidências

Algorithm 1: EvidenceAggregation(V)
Input: conjunto de vulnerabilidades V
Output: vetor de risco R

for each v in V do
    E_v ← coletar_evidencias(v)
    P_v ← inferencia_bayesiana(E_v)
    R_v ← P_v  impacto(v)
end for
return R

A complexidade computacional é aproximadamente $O(n \cdot m)$, onde $m$ representa o número médio de evidências associadas a cada vulnerabilidade.

4.3 Algoritmo 2 — Priorização Baseada em Risco

Algorithm 2: RiskPrioritization(V, B)

ordenar V por R(v) / C(v)

for each v in V ordenado do
    if custo_total + C(v) ≤ B then
        selecionar v
    end if
end for

Embora o problema seja equivalente ao knapsack 0‑1, a estratégia gulosa oferece aproximação eficiente para ambientes operacionais.

5. Implementation

O protótipo foi implementado em ambiente Kubernetes, utilizando uma arquitetura baseada em microserviços.

Principais componentes tecnológicos:

Camada	Tecnologia
SAST	SonarQube
DAST	OWASP ZAP
SCA	Snyk
Telemetria	Elastic Stack
Observabilidade	eBPF-based instrumentation
Banco de dados	PostgreSQL
Motor probabilístico	Python

O pipeline CI/CD foi integrado utilizando GitHub Actions e scanners automatizados executados em cada build.

Escalabilidade foi validada com até 120 pipelines simultâneos, com latência adicional média de 3,4 minutos por execução de pipeline.

6. Experimental Evaluation

6.1 Ambiente Experimental

A avaliação experimental foi conduzida em ambiente corporativo contendo:

• 47 aplicações
• aproximadamente 3,2 milhões de linhas de código
• infraestrutura com servidores de 64 vCPUs e 256 GB RAM

Compararam‑se três configurações.

Configuração	Descrição
Baseline 1	SAST isolado
Baseline 2	SAST + DAST sem correlação
EO‑AppSec	Correlação probabilística completa

As métricas analisadas incluíram precisão, recall, taxa de falsos positivos (FPR) e tempo médio de remediação (MTTR).

6.2 Resultados

Métrica	Baseline 1	Baseline 2	EO‑AppSec
Precisão	0,63	0,71	0,89
Recall	0,78	0,85	0,93
FPR	0,41	0,32	0,18
MTTR (dias)	14,2	11,3	8,7

Observamos redução de 42,3% na taxa de falsos positivos e aumento de 31,5% na detecção de vulnerabilidades efetivamente exploráveis.

O overhead computacional médio foi de aproximadamente 11%, valor considerado aceitável para pipelines DevSecOps de grande escala.

7. Discussion

Os resultados demonstram que a integração probabilística de evidências pode reduzir significativamente o ruído operacional em programas de AppSec. A redução substancial de falsos positivos permite que equipes de engenharia concentrem esforços em vulnerabilidades com maior probabilidade de exploração.

Outro aspecto relevante refere‑se à integração com arquiteturas cloud‑native. Ambientes modernos frequentemente combinam microserviços, APIs externas e componentes baseados em inteligência artificial. Vulnerabilidades clássicas descritas no OWASP Top 10 continuam sendo predominantes, mas novas superfícies de ataque associadas a APIs e modelos de linguagem ampliam o espectro de riscos (OWASP, 2023).

O framework proposto também apresenta sinergia com práticas recomendadas por frameworks de desenvolvimento seguro, como o NIST Secure Software Development Framework (SSDF), que enfatiza automação de verificações de segurança ao longo do ciclo de desenvolvimento (NIST, 2022).

Entretanto, algumas limitações devem ser consideradas. O modelo probabilístico depende da qualidade das evidências coletadas. Dados incompletos ou enviesados podem afetar a estimativa de probabilidade de exploração. Além disso, ambientes com baixa maturidade em telemetria de segurança podem apresentar menor benefício operacional.

Ameaças à validade incluem variabilidade entre projetos e possível sobreajuste do modelo probabilístico a dados históricos específicos do ambiente analisado.

8. Conclusion

Apresentamos EO‑AppSec, um framework formal para orquestração de segurança de aplicações baseada em evidências. O modelo integra múltiplas fontes de análise e utiliza inferência bayesiana para estimar probabilidades de exploração de vulnerabilidades.

A avaliação empírica demonstrou melhorias significativas na priorização de vulnerabilidades, incluindo redução expressiva de falsos positivos e diminuição do tempo médio de remediação.

Esses resultados sugerem que abordagens probabilísticas orientadas a evidências representam um caminho promissor para melhorar a eficácia de programas de AppSec em ambientes DevSecOps e cloud‑native.

Investigações futuras incluem o uso de modelos gráficos probabilísticos mais complexos, integração com análise comportamental em tempo de execução e incorporação de sinais de risco derivados de telemetria de aplicações que utilizam componentes de inteligência artificial.

References

ANTUNES, N.; VIEIRA, M. Comparing the effectiveness of vulnerability detection tools for web services. IEEE International Symposium on Software Reliability Engineering. Disponível em: https://ieeexplore.ieee.org/document/5603957. Acesso em: 10 mar. 2024.

BURP SUITE. Web vulnerability scanner documentation. PortSwigger, 2024. Disponível em: https://portswigger.net/burp. Acesso em: 12 mar. 2024.

CHESS, B.; WEST, J. Secure programming with static analysis. Boston: Addison‑Wesley, 2007. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/secure-programming-with-static-analysis/P200000000482. Acesso em: 10 mar. 2024.

FIRST. Common Vulnerability Scoring System v3.1 specification. 2019. Disponível em: https://www.first.org/cvss/v3.1/specification-document. Acesso em: 11 mar. 2024.

HÖGSTRÖM, A. BPF performance tools: Linux system and application observability. Boston: Addison‑Wesley, 2023. Disponível em: https://www.oreilly.com/library/view/bpf-performance-tools/9780136554820. Acesso em: 12 mar. 2024.

HOWARD, M.; LEBLANC, D. Writing secure code. 2. ed. Redmond: Microsoft Press, 2003. Disponível em: https://learn.microsoft.com/en-us/security/engineering/writing-secure-code. Acesso em: 9 mar. 2024.

JOHNSON, B. et al. Why don’t software developers use static analysis tools to find bugs? IEEE Symposium on Security and Privacy. Disponível em: https://ieeexplore.ieee.org/document/6547103. Acesso em: 10 mar. 2024.

MCGRAW, G. Software security: building security in. Boston: Addison‑Wesley, 2006. Disponível em: https://www.informit.com/store/software-security-building-security-in-9780321356703. Acesso em: 9 mar. 2024.

MITRE. ATT&CK framework. 2023. Disponível em: https://attack.mitre.org. Acesso em: 12 mar. 2024.

MITRE. CVE‑2021‑44228: Apache Log4j remote code execution vulnerability. 2021. Disponível em: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228. Acesso em: 10 mar. 2024.

MITRE. CVE‑2023‑34362: MOVEit transfer vulnerability. 2023. Disponível em: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34362. Acesso em: 10 mar. 2024.

MENEELY, A. et al. Predicting vulnerabilities with software metrics. ACM Conference on Computer and Communications Security. Disponível em: https://dl.acm.org/doi/10.1145/2382196.2382205. Acesso em: 10 mar. 2024.

NIST. Secure software development framework (SSDF). NIST SP 800‑218, 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 10 mar. 2024.

NIST. Security and privacy controls for information systems and organizations. NIST SP 800‑53 Rev.5, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Acesso em: 10 mar. 2024.

OWASP FOUNDATION. OWASP Top 10: The ten most critical web application security risks. 2021. Disponível em: https://owasp.org/www-project-top-ten. Acesso em: 11 mar. 2024.

OWASP FOUNDATION. OWASP Top 10 for Large Language Model Applications. 2023. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications. Acesso em: 12 mar. 2024.

OWASP FOUNDATION. Application Security Verification Standard (ASVS). 2022. Disponível em: https://owasp.org/www-project-application-security-verification-standard. Acesso em: 11 mar. 2024.

SCARFONE, K.; PADGETT, M. Guide to securing cloud-native containerized environments. NIST, 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acesso em: 10 mar. 2024.

SNYK. State of open source security report 2023. Disponível em: https://snyk.io/reports/open-source-security. Acesso em: 12 mar. 2024.

SONARQUBE. Static code analysis documentation. SonarSource, 2024. Disponível em: https://docs.sonarsource.com/sonarqube. Acesso em: 12 mar. 2024.

VERIZON. 2023 data breach investigations report. Disponível em: https://www.verizon.com/business/resources/reports/dbir. Acesso em: 10 mar. 2024.

WALDEN, J.; DOYLE, M.; WELCH, J. Static analysis tools comparison for vulnerability detection. International Conference on Software Engineering. Disponível em: https://dl.acm.org/doi/10.1145/1555001.1555028. Acesso em: 10 mar. 2024.

ZIMMERMANN, T. et al. Mining version histories to guide software changes. IEEE Transactions on Software Engineering, 2005. Disponível em: https://ieeexplore.ieee.org/document/1463106. Acesso em: 9 mar. 2024.

ISO. ISO/IEC 27034‑1: Information technology — application security. Geneva: ISO, 2011. Disponível em: https://www.iso.org/standard/44378.html. Acesso em: 10 mar. 2024.

FALCO PROJECT. Runtime security for cloud-native environments. 2024. Disponível em: https://falco.org. Acesso em: 12 mar. 2024.