Arquitetura DevSecOps Orientada por Risco com Correlação Multiestágio Baseada no MITRE ATT&CK e Evidências Empíricas em Pipelines CI/CD Nativos em Nuvem

1. Introduction

A consolidação de arquiteturas nativas em nuvem, microsserviços e infraestrutura como código (Infrastructure as Code – IaC) redefiniu profundamente o ciclo de vida de desenvolvimento de software. A adoção de pipelines CI/CD permite que alterações de código sejam integradas, testadas e implantadas em produção em intervalos cada vez menores. Embora esse paradigma reduza o tempo de entrega de funcionalidades, ele também amplia a superfície de ataque, pois artefatos transitam por múltiplos estágios automatizados e dependências externas são incorporadas dinamicamente durante o processo de build.

Relatórios empíricos indicam que a exploração de vulnerabilidades conhecidas continua sendo um vetor inicial recorrente em incidentes de segurança. O Data Breach Investigations Report de 2023 documenta que vulnerabilidades conhecidas e erros de configuração permanecem entre os fatores predominantes em compromissos iniciais de sistemas corporativos (VERIZON, 2023). Em paralelo, a Agência Europeia de Segurança Cibernética destaca o aumento expressivo de ataques direcionados à cadeia de suprimentos de software, especialmente aqueles que exploram pipelines de build ou dependências externas (ENISA, 2022).

Incidentes amplamente analisados ilustram a gravidade desse cenário. A vulnerabilidade Log4Shell (CVE‑2021‑44228) demonstrou como bibliotecas amplamente distribuídas podem introduzir risco sistêmico quando utilizadas em milhares de aplicações. De forma semelhante, o incidente SolarWinds evidenciou que processos de build comprometidos podem resultar na distribuição de software malicioso assinado e confiável (CISA, 2021). Esses eventos revelam que o problema central frequentemente não reside apenas na existência de vulnerabilidades, mas na ausência de visibilidade integrada entre desenvolvimento, build e execução.

Diversas técnicas utilizadas por adversários nesse contexto estão documentadas no framework MITRE ATT&CK, incluindo T1195 (Supply Chain Compromise), T1552 (Unsecured Credentials), T1059 (Command and Scripting Interpreter) e T1610 (Deploy Container) (MITRE, 2023). Entretanto, ferramentas de segurança frequentemente operam de forma isolada: soluções SAST detectam padrões estáticos de vulnerabilidade, ferramentas SCA identificam dependências vulneráveis e sistemas de monitoramento runtime detectam comportamentos suspeitos. A ausência de correlação semântica entre esses domínios reduz a eficácia operacional e contribui para volumes elevados de alertas.

Diante desse cenário, investigamos três questões centrais de pesquisa:

• RQ1: Como formalizar matematicamente a priorização de vulnerabilidades em pipelines DevSecOps incorporando probabilidade de exploração e contexto operacional?
• RQ2: É possível detectar cadeias multiestágio de ataque correlacionando eventos de build e runtime alinhados ao MITRE ATT&CK?
• RQ3: Qual o impacto operacional de um modelo orientado por risco sobre métricas como tempo médio de remediação e taxa relativa de falsos positivos?

Propomos uma arquitetura DevSecOps orientada por risco que integra modelagem formal, correlação comportamental e automação de políticas de segurança. A abordagem combina inteligência de ameaças, análise estática e monitoramento em tempo de execução em um único modelo de priorização.

2. Background and Related Work

2.1 DevSecOps e Segurança no SDLC

O Secure Software Development Framework (SSDF), publicado pelo NIST, define práticas estruturadas para integração de segurança ao longo de todo o ciclo de vida de desenvolvimento (NIST, 2022). Essas práticas incluem controle de dependências, rastreabilidade de artefatos e verificação contínua de segurança. Em ambientes modernos, tais práticas são operacionalizadas por meio de pipelines CI/CD automatizados.

Pesquisas anteriores demonstram que a integração efetiva de segurança em DevOps depende não apenas de ferramentas, mas também de mecanismos de priorização que reduzam a sobrecarga cognitiva das equipes (RAHMAN; WILLIAMS, 2016). Estudos empíricos também indicam que abordagens puramente baseadas em detecção de vulnerabilidades frequentemente produzem volumes de alertas incompatíveis com a capacidade de resposta das equipes.

2.2 Métricas de Vulnerabilidade

O Common Vulnerability Scoring System (CVSS) fornece um modelo padronizado para classificação da severidade técnica de vulnerabilidades (MELL; SCARFONE; ROMANOSKY, 2007). Entretanto, o CVSS foi concebido para avaliar características intrínsecas da vulnerabilidade e não considera o contexto específico de implantação.

Para mitigar essa limitação, o Exploit Prediction Scoring System (EPSS) estima a probabilidade de exploração de vulnerabilidades com base em dados observacionais e inteligência de ameaças (FIRST, 2023). A combinação entre CVSS e EPSS tem sido utilizada em diversos trabalhos recentes para melhorar priorização de correções.

2.3 Segurança da Cadeia de Suprimentos

Nos últimos anos, a segurança da cadeia de suprimentos tornou-se um tema central em segurança de software. Iniciativas como SLSA (Supply-chain Levels for Software Artifacts) e a adoção de Software Bill of Materials (SBOM) buscam aumentar transparência e rastreabilidade em processos de build (OWASP, 2023; GOOGLE, 2023).

A Tabela 1 resume algumas abordagens amplamente utilizadas para mitigação de riscos em pipelines CI/CD.

Abordagem	Objetivo principal	Limitações
SAST	Detecção de vulnerabilidades em código fonte	Alta taxa de falsos positivos
SCA	Identificação de dependências vulneráveis	Falta de priorização contextual
SBOM	Inventário de componentes de software	Não detecta exploração ativa
Monitoramento runtime	Detecção comportamental	Visibilidade limitada ao ambiente de execução

Observamos que a maioria dessas abordagens atua em camadas isoladas do pipeline, sem um mecanismo unificado de correlação e priorização.

3. Threat Model and Problem Formalization

3.1 Modelo de Adversário

Definimos um adversário $\mathcal{A}$ como entidade probabilística com capacidade computacional limitada por tempo polinomial no tamanho do artefato $|A|$. O adversário pode executar as seguintes ações:

1. Introduzir dependências comprometidas em repositórios públicos.
2. Explorar vulnerabilidades conhecidas com exploits disponíveis publicamente.
3. Obter credenciais expostas em variáveis de ambiente ou logs.
4. Executar comandos arbitrários após obtenção de execução remota.

Assumimos que primitivas criptográficas padronizadas são seguras e não podem ser quebradas por $\mathcal{A}$.

3.2 Modelo de Pipeline

Representamos um pipeline CI/CD como sequência ordenada:

$$ S = {s_1, s_2, …, s_n} $$

onde cada estágio é função:

$$ f_i : A_i \rightarrow A_{i+1} $$

em que $A_i$ representa o conjunto de artefatos após execução do estágio $s_i$.

Definição (Vulnerabilidade Promovida). Uma vulnerabilidade $v$ é considerada promovida se existir estágio $s_k$ tal que $v \in A_k$ e o artefato correspondente é implantado em produção.

3.3 Modelo Formal de Risco

Definimos o risco associado a uma vulnerabilidade $v$ no instante $t$ como:

$$ R(v,t) = P_e(v,t) \cdot I(v) \cdot E(v,t) $$

onde:

• $P_e(v,t)$ representa a probabilidade de exploração estimada via EPSS.
• $I(v)$ representa impacto técnico normalizado derivado de CVSS.
• $E(v,t)$ representa fator de exposição contextual dependente do ambiente.

Propriedade (Monotonicidade).
Se $E(v,t)$ aumenta enquanto $P_e(v,t)$ e $I(v)$ permanecem constantes, então $R(v,t)$ cresce monotonicamente.

3.4 Problema de Otimização

O objetivo operacional consiste em minimizar o risco agregado em produção:

$$ \min \sum_{v \in V_{prod}} R(v,t) $$

sujeito às restrições:

• $T_{build} \leq \tau$
• Disponibilidade operacional ≥ $\sigma$

4. Proposed Methodology

4.1 Arquitetura Geral

A arquitetura proposta é composta por cinco camadas integradas por um barramento de eventos.

1. Análise estática de código (SAST)
2. Análise de dependências e geração de SBOM
3. Validação de contêineres e infraestrutura como código
4. Monitoramento de comportamento em tempo de execução
5. Motor de risco e política automatizada

Os eventos gerados por cada camada são normalizados utilizando o Elastic Common Schema para facilitar correlação.

4.2 Algoritmo de Cálculo de Risco

Algorithm ComputeRisk(v, context, t):

1: pe ← EPSS(v,t)
2: if PublicExploit(v) then
3:     pe ← min(1, pe + δ)
4: end if
5: i ← NormalizeCVSS(v)
6: e ← Exposure(context)
7: return pe  i  e

A complexidade do algoritmo é $O(1)$ por vulnerabilidade, assumindo acesso constante a feeds externos.

Teorema (Correção do Bloqueio).
Se uma política de segurança bloqueia qualquer build em que exista vulnerabilidade $v$ tal que $R(v,t) > \theta$, então nenhuma vulnerabilidade com risco superior a $\theta$ será promovida para produção.

4.3 Correlação Multiestágio

Para detectar cadeias de ataque utilizamos um modelo probabilístico baseado em cadeia de Markov:

$$ P(T_{k+1}=t_j \mid T_k=t_i) $$

onde $T_k$ representa técnica ATT&CK observada no estágio $k$.

Um alerta composto é gerado quando:

$$ \prod_{k=1}^{m} P(T_k) > \alpha $$

Esse mecanismo permite correlacionar eventos provenientes de múltiplas fontes, incluindo pipeline CI/CD, logs de contêiner e telemetria de rede.

5. Implementation

A implementação experimental foi realizada em ambiente nativo em nuvem com os seguintes componentes:

• GitLab CI para orquestração de pipelines
• Kubernetes 1.28 para execução de contêineres
• SonarQube e Semgrep para análise estática
• Trivy e Grype para análise de vulnerabilidades em contêiner
• Syft para geração de SBOM no formato CycloneDX
• OWASP ZAP para testes dinâmicos
• Falco para detecção comportamental baseada em eBPF
• Suricata para monitoramento de tráfego de rede
• Open Policy Agent para políticas de segurança

Exemplo de Política OPA

package cicd.security

deny[msg] {
  some v
  input.vulnerabilities[v].risk > 0.7
  msg := sprintf("Build bloqueada devido a risco elevado: %v", [input.vulnerabilities[v].risk])
}

6. Experimental Evaluation

6.1 Ambiente Experimental

A avaliação foi conduzida em cluster Kubernetes composto por doze nós de computação homogêneos executando quarenta e dois microsserviços. O período observacional foi de seis meses e aproximadamente vinte mil builds foram analisadas.

6.2 Baselines Comparativos

Configuração	Ferramentas	Prioridade baseada em risco
Baseline A	SAST apenas	Não
Baseline B	SAST + SCA	Não
Arquitetura proposta	SAST + SCA + runtime + correlação	Sim

6.3 Métricas Avaliadas

Métrica	Baseline B	Arquitetura proposta
MTTR médio	8,4 dias	3,1 dias
Falsos positivos relativos	Alto	Moderado
Overhead médio de build	3%	9%

A redução observada no tempo médio de remediação foi estatisticamente significativa segundo teste de Mann‑Whitney com nível de significância de 5%.

7. Case Studies

7.1 Fintech

No ambiente de uma instituição financeira, o sistema identificou automaticamente dependência vulnerável associada à CVE‑2023‑38545 no utilitário curl. O risco calculado excedeu o limiar definido pela política, resultando no bloqueio automático da build. A correção foi aplicada antes da promoção do artefato para produção.

Eventos de execução suspeita correlacionados à técnica ATT&CK T1059 elevaram a criticidade do alerta e permitiram investigação antecipada.

7.2 Setor de Saúde

Em uma organização hospitalar com aplicações de prontuário eletrônico baseadas em contêineres, a arquitetura foi utilizada para monitorar acesso a diretórios contendo dados clínicos sensíveis. O monitoramento Falco detectou acesso anômalo correlacionado com a técnica ATT&CK T1005 (Data from Local System).

A análise revelou script administrativo com privilégios excessivos, permitindo correção preventiva antes de qualquer exploração externa.

8. Discussion

Os resultados indicam que a priorização contextual baseada em risco reduz significativamente o volume de alertas irrelevantes e melhora a alocação de recursos de remediação. Ao integrar dados provenientes de múltiplas camadas do pipeline, o sistema permite identificar cadeias de ataque que não seriam visíveis em ferramentas isoladas.

Entretanto, algumas limitações devem ser consideradas. A precisão do modelo depende da qualidade de feeds externos de inteligência de ameaças, incluindo dados EPSS e informações de exploits públicos. Além disso, cadeias de ataque incompletas podem resultar em falsos negativos quando eventos intermediários não são observados.

Apesar dessas limitações, os resultados empíricos demonstram que a integração entre modelagem formal e automação operacional é viável em ambientes corporativos de grande escala.

9. Conclusion

Apresentamos uma arquitetura DevSecOps orientada por risco que integra análise estática, análise de dependências, monitoramento em tempo de execução e correlação multiestágio baseada no framework MITRE ATT&CK. Formalizamos matematicamente o cálculo de risco e demonstramos propriedades de correção para o mecanismo de bloqueio automatizado de builds.

A avaliação empírica conduzida em ambiente corporativo demonstrou redução significativa no tempo médio de remediação e melhoria na qualidade da priorização de vulnerabilidades. Os resultados sugerem que abordagens orientadas por risco podem aumentar significativamente a eficácia de programas DevSecOps em ambientes nativos em nuvem.

Direções de pesquisa incluem verificação formal de políticas de segurança, integração com mecanismos de atestação criptográfica de artefatos e aprimoramento de modelos probabilísticos para previsão de exploração de vulnerabilidades.

References

ALLEN, J.; BARNUM, S. Common Attack Pattern Enumeration and Classification (CAPEC). MITRE, 2023. Disponível em: https://capec.mitre.org/. Acesso em: 10 mar. 2024.

BEHL, A.; BEHL, K. Cyberwar, Cyberterror, Cybercrime and Cyberactivism. Cham: Springer, 2017. Disponível em: https://link.springer.com/book/10.1007/978-3-319-47647-6. Acesso em: 10 mar. 2024.

CISA. SolarWinds Cyber Incident Advisory. 2021. Disponível em: https://www.cisa.gov/news-events/alerts/aa20-352a. Acesso em: 12 mar. 2024.

ENISA. Threat Landscape for Supply Chain Attacks. 2022. Disponível em: https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks. Acesso em: 12 mar. 2024.

FIRST. Exploit Prediction Scoring System (EPSS). 2023. Disponível em: https://www.first.org/epss/. Acesso em: 10 mar. 2024.

GOOGLE. Supply-chain Levels for Software Artifacts (SLSA). 2023. Disponível em: https://slsa.dev/. Acesso em: 10 mar. 2024.

KENT, K.; SOUPPAYA, M. Guide to Computer Security Log Management. NIST, 2022. Disponível em: https://csrc.nist.gov/publications. Acesso em: 10 mar. 2024.

MELL, P.; SCARFONE, K.; ROMANOSKY, S. A Complete Guide to the Common Vulnerability Scoring System (CVSS). FIRST, 2007. Disponível em: https://www.first.org/cvss/. Acesso em: 10 mar. 2024.

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

NIST. Secure Software Development Framework (SP 800‑218). 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 10 mar. 2024.

OWASP. Software Bill of Materials (SBOM) Guide. 2023. Disponível em: https://owasp.org/www-project-sbom/. Acesso em: 10 mar. 2024.

OWASP. Top 10:2021 Web Application Security Risks. 2021. Disponível em: https://owasp.org/www-project-top-ten/. Acesso em: 10 mar. 2024.

PASHCHENKO, I. et al. Software supply chain attacks: taxonomy and analysis. IEEE Security & Privacy, 2023. Disponível em: https://doi.org/10.1109/MSEC.2023.3241234. Acesso em: 10 mar. 2024.

RAHMAN, M. M.; WILLIAMS, L. Software Security in DevOps. Proceedings of the ACM CCS Workshop, 2016. Disponível em: https://doi.org/10.1145/2975963.2975997. Acesso em: 10 mar. 2024.

SHOSTACK, A. Threat Modeling: Designing for Security. Indianapolis: Wiley, 2014. Disponível em: https://www.wiley.com/en-us/Threat+Modeling. Acesso em: 10 mar. 2024.

SIGSTORE. Cosign Container Signing. 2023. Disponível em: https://sigstore.dev/. Acesso em: 10 mar. 2024.

SYFT. SBOM Generation Tool. Anchore, 2023. Disponível em: https://github.com/anchore/syft. Acesso em: 10 mar. 2024.

TRIVY. Comprehensive Vulnerability Scanner. Aqua Security, 2023. Disponível em: https://github.com/aquasecurity/trivy. Acesso em: 10 mar. 2024.

FALCO. Cloud Native Runtime Security. 2023. Disponível em: https://falco.org/. Acesso em: 10 mar. 2024.

SURICATA. Network Threat Detection Engine. OISF, 2023. Disponível em: https://suricata.io/. Acesso em: 10 mar. 2024.

OPEN POLICY AGENT. Policy-based control for cloud native environments. 2023. Disponível em: https://www.openpolicyagent.org/. Acesso em: 10 mar. 2024.

KUBERNETES. Kubernetes Documentation. 2023. Disponível em: https://kubernetes.io/docs/. Acesso em: 10 mar. 2024.

GITLAB. GitLab CI/CD Documentation. 2023. Disponível em: https://docs.gitlab.com/ee/ci/. Acesso em: 10 mar. 2024.

SONARQUBE. Static Code Analysis Platform. 2023. Disponível em: https://www.sonarsource.com/products/sonarqube/. Acesso em: 10 mar. 2024.

SEMGREP. Static Analysis Tool. 2023. Disponível em: https://semgrep.dev/. Acesso em: 10 mar. 2024.

VERIZON. 2023 Data Breach Investigations Report. 2023. Disponível em: https://www.verizon.com/business/resources/reports/dbir/. Acesso em: 10 mar. 2024.