Bellacosa Mainframe teste seu sistema sob ataque

🔥💀 VOCÊ APRENDEU SEGURANÇA… MAS JÁ TESTOU SEU SISTEMA SOB ATAQUE?

10 atividades práticas para sair da teoria e começar a proteger sistemas de verdade

---

☕ INTRODUÇÃO — A VERDADE QUE DÓI

Segurança não se aprende lendo.
👉 Se aprende quebrando sistema… e depois corrigindo.

Se você não praticar:

💣 você só vai descobrir o problema… quando o atacante descobrir primeiro.

---

🧪 ATIVIDADE 1 — ENCONTRE UM SQL INJECTION NO SEU PRÓPRIO SISTEMA

🎯 Objetivo

Pensar como atacante

---

💻 Faça isso

• Pegue um input (API, tela, CICS, batch input)
• Teste:

' OR 1=1 --

---

💥 Resultado esperado

👉 Se algo estranho acontecer… você tem vulnerabilidade

---

🧠 Versão COBOL

• validar WS-FIELD
• nunca confiar em input externo

---

💬 Comentário

“Se você não testar… alguém vai testar por você.”

---

🧪 ATIVIDADE 2 — REMOVA TODOS OS HARDCODED SECRETS

🎯 Objetivo

Eliminar o erro mais comum do mundo

---

💻 Procure no seu código

password
token
key
secret

---

💥 Se encontrar:

👉 você tem risco crítico

---

✅ Solução

• usar Vault / RACF
• variáveis externas

---

💬 Easter egg

👉 80% dos vazamentos começam assim

---

🧪 ATIVIDADE 3 — RODE UM SCAN DE SEGURANÇA

🎯 Objetivo

Ver o que você não vê

---

💻 Ferramentas

• Snyk
• SonarQube

---

💥 Resultado

👉 lista de vulnerabilidades reais

---

💬 Comentário

“Scanner não cria problema… só revela.”

---

🧪 ATIVIDADE 4 — EXPLORE UM XSS NA PRÁTICA

🎯 Objetivo

Ver o ataque funcionando

---

💻 Teste

<script>alert('XSS')</script>

---

💥 Resultado

👉 se executar → vulnerável

---

🧠 Versão real

• portais corporativos
• front-end conectado ao mainframe

---

🧪 ATIVIDADE 5 — ATUALIZE UMA DEPENDÊNCIA VULNERÁVEL

🎯 Objetivo

Entender SCA na prática

---

💻 Faça

• rode scan
• escolha uma lib vulnerável
• atualize

---

💥 Resultado

👉 CVE desaparece

---

💬 Comentário

“Seu código pode estar perfeito… sua lib não.”

---

🧪 ATIVIDADE 6 — QUEBRE SEU PRÓPRIO LOGIN

🎯 Objetivo

Pensar como invasor

---

💻 Teste

• inputs inválidos
• SQL injection
• brute force simples

---

💥 Resultado

👉 encontrar bypass

---

💬 Comentário

“Se login falha… todo sistema falha.”

---

🧪 ATIVIDADE 7 — IMPLEMENTE HEADERS DE SEGURANÇA

🎯 Objetivo

Blindar camada web

---

💻 Adicionar

• Content-Security-Policy
• HSTS
• X-Frame-Options

---

💥 Resultado

👉 reduz ataque XSS e clickjacking

---

🧪 ATIVIDADE 8 — CRIPTOGRAFE UM ARQUIVO SENSÍVEL

🎯 Objetivo

Proteger dados em repouso

---

💻 Use OpenSSL

openssl enc -aes-256-cbc -salt -pbkdf2 -iter 2500

---

💥 Resultado

👉 arquivo ilegível sem senha

---

💬 Comentário

“Dado sem criptografia é dado público.”

---

🧪 ATIVIDADE 9 — CRIE UM MINI PIPELINE DE SEGURANÇA

🎯 Objetivo

Automação

---

💻 Simule

commit → scan → resultado → bloqueio

---

💥 Resultado

👉 segurança contínua

---

🧠 Versão mainframe

• Jenkins + JCL + scan

---

🧪 ATIVIDADE 10 — FAÇA UM “ATAQUE CONTROLADO”

🎯 Objetivo

Pensar como hacker

---

💻 Faça

• use OWASP ZAP
• ataque sua própria aplicação

---

💥 Resultado

👉 visão real de risco

---

💬 Comentário

“Sistema seguro é sistema testado sob ataque.”

---

🧠 CONCLUSÃO — O DIFERENCIAL REAL

Depois dessas 10 atividades, você não é mais:

👉 um dev que escreve código

Você é:

👉 alguém que entende como o sistema quebra… e como evitar isso

---

💬 FRASE FINAL

“Segurança não é o que você implementa…
é o que sobrevive quando alguém tenta quebrar.”

 

 

Bellacosa Mainframe lab seu cics sob ataque

🔥💀 COBOL SECURITY LAB — “SEU CICS SOB ATAQUE”

Hands-on prático com CICS + DB2 para aprender segurança na marra

---

☕ INTRODUÇÃO

Você não vai só aprender…

👉 você vai:

• explorar vulnerabilidade
• corrigir
• validar

💣 exatamente como um atacante faria

---

🧪 LAB 1 — SQL INJECTION NO DB2

🎯 Objetivo

Mostrar como um COBOL pode ser vulnerável

---

💻 Código vulnerável

IDENTIFICATION DIVISION.
PROGRAM-ID. LOGIN.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-USER     PIC X(20).
01 WS-PASS     PIC X(20).

PROCEDURE DIVISION.

EXEC SQL
  SELECT NAME INTO :WS-USER
  FROM USERS
  WHERE NAME = :WS-USER
  AND PASSWORD = :WS-PASS
END-EXEC.

---

💣 Ataque

Input:

' OR '1'='1

---

💥 Resultado

👉 bypass de autenticação

---

✅ Correção

IF WS-USER NOT ALPHABETIC
   DISPLAY "INVALID INPUT"
   STOP RUN
END-IF.

---

💬 Insight

👉 validação é a primeira defesa

---

🧪 LAB 2 — BUFFER / TAMANHO DE INPUT

🎯 Objetivo

Evitar overflow e dados inválidos

---

💻 Problema

01 WS-NAME PIC X(10).

Input:

AAAAAAAAAAAAAAAAAAAAAAAAAAAA

---

💥 Resultado

👉 truncamento / corrupção

---

✅ Correção

IF LENGTH OF WS-NAME > 10
   DISPLAY "INPUT TOO LONG"
END-IF.

---

🧪 LAB 3 — HARDCODED PASSWORD

🎯 Objetivo

Eliminar segredo no código

---

❌ Código

MOVE "DB123456" TO WS-PASS.

---

💣 Problema

👉 vazamento garantido

---

✅ Correção

• usar RACF
• usar external security

👉 RACF

---

🧪 LAB 4 — VALIDAÇÃO DE COMMAREA (CICS)

🎯 Objetivo

Proteger entrada CICS

---

💻 Código vulnerável

MOVE DFHCOMMAREA TO WS-DATA.

---

💣 Problema

👉 dados maliciosos

---

✅ Correção

IF EIBCALEN = 0
   DISPLAY "NO DATA"
   RETURN
END-IF.

---

🧪 LAB 5 — LOGGING SEGURO

🎯 Objetivo

Evitar vazamento de dados

---

❌ Errado

DISPLAY "PASSWORD: " WS-PASS.

---

💣 Problema

👉 senha em log

---

✅ Correção

DISPLAY "LOGIN ATTEMPT".

---

🧪 LAB 6 — CONTROLE DE ACESSO (RACF)

🎯 Objetivo

Simular autorização

---

💻 Exemplo

CALL 'RACROUTE' USING ...

---

💬 Resultado

👉 só usuários autorizados acessam

---

🧪 LAB 7 — INTEGRAÇÃO COM API (RISCO REAL)

🎯 Objetivo

Simular API via CICS

---

💣 Problema

👉 input externo não confiável

---

✅ Solução

• validar JSON
• sanitizar campos

---

🧪 LAB 8 — TRATAMENTO DE ERRO

🎯 Objetivo

Não expor sistema

---

❌ Errado

DISPLAY SQLCODE.

---

💣 Problema

👉 revela estrutura interna

---

✅ Correto

DISPLAY "ERROR OCCURRED".

---

🧪 LAB 9 — CONTROLE DE TRANSAÇÃO

🎯 Objetivo

Evitar inconsistência

---

💻 Uso

EXEC CICS SYNCPOINT
END-EXEC.

---

💬 Importante

👉 protege integridade

---

🧪 LAB 10 — SIMULAR ATAQUE REAL

🎯 Objetivo

Mentalidade hacker

---

💻 Faça

• testar inputs inválidos
• tentar bypass
• observar comportamento

---

💥 Resultado

👉 descobrir falhas reais

---

🧠 VISÃO FINAL

Você fez:

• ataque
• defesa
• validação

👉 isso é segurança real

---

💬 FRASE FINAL

“Mainframe não é seguro por ser forte…
é seguro quando você fecha as portas certas.”

 

Bellacosa Mainframe apresenta segurança em codigo

🔥💀 “SEU CÓDIGO ESTÁ SEGURO… OU SÓ AINDA NÃO FOI HACKEADO?”

Do Cartão Perfurado ao DevSecOps: como as mesmas falhas continuam derrubando sistemas — inclusive o seu

---

☕ INTRODUÇÃO — O ERRO QUE ATRAVESSOU DÉCADAS

Se você acha que segurança de aplicação é algo “moderno”…

👉 você já começou errado.

Há mais de 20 anos, os mesmos problemas que aparecem hoje na lista da OWASP já existiam.

E o mais assustador:

💣 Eles continuam sendo explorados hoje.

---

🧠 UM POUCO DE HISTÓRIA (SIM, ISSO COMEÇA NO MAINFRAME)

Antes de:

• APIs REST
• microservices
• cloud

…existia:

🧱 Mainframe + COBOL + CICS + DB2

E adivinha?

👉 Os mesmos problemas já estavam lá:

• input sem validação
• acesso indevido
• dados sensíveis expostos

---

💀 EASTER EGG HISTÓRICO

Nos anos 70–80, segurança era baseada em:

👉 “ninguém tem acesso físico ao terminal”

Spoiler:

💣 isso não durou muito

---

🔐 O NASCIMENTO DA SEGURANÇA REAL

Ferramentas como o RACF surgiram para resolver:

• quem pode acessar
• o que pode acessar
• quando pode acessar

👉 primeiro passo para segurança moderna

---

💣 O PROBLEMA REAL: NÃO É TECNOLOGIA

👉 É comportamento

Hoje temos:

• scanners
• IA
• automação
• cloud

E mesmo assim…

💥 vazamentos continuam acontecendo

---

📊 DADO REAL (que assusta)

Tempo médio para detectar um breach:

👉 ~212 dias

Tempo suficiente para:

• invadir
• explorar
• exfiltrar dados
• desaparecer

---

🔥 OWASP TOP 10 — O MANUAL DO ATACANTE

A OWASP lista os erros mais explorados.

E aqui vai o choque:

👉 quase todos são básicos

---

💣 EXEMPLO 1 — SQL INJECTION (O DINOSSAURO QUE AINDA MATA)

' OR 1=1 --

👉 isso ainda quebra sistemas hoje

---

💣 EXEMPLO 2 — XSS (VOCÊ CONFIA NO USUÁRIO?)

<script>stealCookies()</script>

👉 o browser executa
👉 o atacante assume a sessão

---

💣 EXEMPLO 3 — DEPENDÊNCIAS VULNERÁVEIS

Você escreve:

👉 20% do código

O resto?

👉 bibliotecas externas 😬

---

🛠️ DEVSECOPS — A VIRADA DE JOGO

Antes:

👉 segurança era responsabilidade de outro time

Hoje:

👉 “You build it, you run it… and you secure it.”

---

🔄 PIPELINE MODERNO

code → scan → test → deploy → monitor

Ferramentas:

• SAST (ex: análise estática)
• DAST (ataque simulado)
• SCA (dependências)
• runtime protection

---

🧪 MÃO NA MASSA (O QUE VOCÊ PRATICOU)

Você fez:

🔍 SAST

• analisou código sem rodar

---

🌐 DAST

• atacou a aplicação com ferramentas

---

📦 SCA

• descobriu vulnerabilidade em libs

---

🔐 Secrets

• saiu do hardcode → Vault

---

🐳 Docker Security

• corrigiu imagem vulnerável

---

👉 isso é exatamente o que empresas fazem hoje

---

💀 ERRO CLÁSSICO (QUE DERRUBA EMPRESA)

password = "123456"

👉 parece inofensivo

👉 vira incidente milionário

---

🧠 A VERDADE QUE NINGUÉM TE CONTA

👉 Segurança não falha por falta de ferramenta

👉 Segurança falha por:

• pressa
• ignorância
• negligência

---

🔥 CURIOSIDADE (QUE MUDA SUA VISÃO)

O maior ataque da história recente (Log4j):

👉 veio de uma biblioteca

Não do código principal

---

🚀 DO DEV AO ENGENHEIRO DE SEGURANÇA

Depois desse conhecimento, você não é mais só dev:

👉 você entende:

• como atacar
• como defender
• onde estão os riscos

---

🧱 E O COBOL NISSO TUDO?

Tudo isso se aplica em:

• CICS
• DB2
• APIs via z/OS Connect

---

👉 Mainframe não é imune
👉 ele só é mais disciplinado

---

💬 FRASE PRA GRAVAR

“Você não precisa ser hackeado para estar vulnerável…
basta ignorar o básico.”

---

🔥 CONCLUSÃO (SEM FILTRO)

👉 Se você não:

• valida input
• protege secrets
• escaneia dependências
• monitora

💣 seu sistema já está em risco

---

🚀 CHAMADA FINAL

Agora você tem duas opções:

👉 continuar escrevendo código
ou
👉 começar a proteger sistemas

 

Bellacosa Mainframe apresenta o OWASP para Analistas programadores COBOL 

💀🔐 “OWASP NÃO É SOBRE WEB… É SOBRE SOBREVIVER — O Guia que Todo Dev COBOL Sênior Ignora Até Ser Tarde”

---

☕ Introdução — o incômodo necessário

Se você trabalha com COBOL há anos, já deve ter ouvido isso:

“Mainframe é seguro por natureza.”

Agora deixa eu ajustar essa frase:

“Mainframe é robusto…
mas segurança depende de você.”

E é exatamente aqui que entra o
👉 OWASP

---

🧠 O que é OWASP (sem enrolação)

OWASP é uma organização global que reúne especialistas para responder uma pergunta simples:

“Como sistemas são invadidos… de verdade?”

E mais importante:

“Como evitar isso?”

---

💡 A essência do OWASP

• Não vende produto
• Não é vendor
• Não é marketing

👉 É conhecimento aberto baseado em ataques reais

---

⏳ Origem — por que isso nasceu?

No início dos anos 2000:

• Aplicações web explodindo
• Segurança praticamente ignorada
• Desenvolvedores focados só em “fazer funcionar”

Resultado?

💣 Sistemas sendo quebrados com facilidade ridícula

Foi aí que nasceu o OWASP.

---

🎯 Objetivo inicial

Criar um guia simples:

“Aqui estão as formas mais comuns de te hackearem.”

---

💣 OWASP Top 10 — o mapa do inimigo

Esse é o coração do projeto:

👉 OWASP Top 10

Uma lista das vulnerabilidades mais críticas.

---

⚠️ Easter Egg #1

Muitas falhas do Top 10 existem há mais de 15 anos

E continuam acontecendo.

---

🔥 Exemplos que batem direto no seu COBOL

1) Injection (SQL Injection)

EXEC SQL
 SELECT * FROM USERS
 WHERE NAME = :WS-NAME
END-EXEC

💀 Sem validação → vulnerável

---

2) Broken Access Control

• Usuário acessa dados que não deveria
• Falha de lógica, não de tecnologia

👉 clássico em CICS mal desenhado

---

3) Sensitive Data Exposure

MOVE "123456" TO WS-PASSWORD

💣 Parabéns, você criou um incidente

---

4) Security Misconfiguration

• RACF mal configurado
• Permissões abertas
• Ambientes sem controle

---

🧠 O ponto que muda tudo

OWASP não fala de linguagem.

Ele fala de comportamento.

---

💬 Tradução direta

• Não importa se é COBOL, Java ou Node
• Se você confiar no input → você perde
• Se você expor segredo → você perde
• Se você não validar → você perde

---

🔍 Como isso entra no seu dia a dia (COBOL + CICS + DB2)

Cenário real moderno:

• API REST → chama CICS
• Frontend → envia dados
• DB2 → executa query

👉 Isso é um ambiente OWASP puro

---

⚠️ Easter Egg #2

O ataque começa no browser…
e termina no seu programa COBOL

---

🧨 OWASP na prática (não teórica)

💥 Fluxo real de ataque:

1. Input malicioso entra via API
2. Passa sem validação
3. Chega no COBOL
4. Executa lógica indevida
5. Acesso indevido ao DB2
6. Logs não detectam

👉 invasor dentro por meses

---

🛠️ Como usar OWASP na prática (PASSO A PASSO)

---

🥇 PASSO 1 — Pare de confiar no input

“Tudo que vem de fora é suspeito.”

• Tela
• API
• arquivo
• integração

---

🥈 PASSO 2 — Validação forte

• tamanho
• tipo
• conteúdo

👉 não é “IF != SPACE” 😅

---

🥉 PASSO 3 — Proteja secrets

• nunca em código
• usar RACF corretamente
• ou vault externo

---

🏅 PASSO 4 — Monitore comportamento

• logs
• acessos estranhos
• padrões anormais

---

🎖️ PASSO 5 — Use o stack moderno

• SAST → antes de rodar
• DAST → testando ataque
• SCA → dependências

👉 DevSecOps

---

🧩 Curiosidades que poucos sabem

---

🧠 Curiosidade #1

OWASP é mantido por voluntários.

👉 os melhores especialistas do mundo colaboram de graça

---

💣 Curiosidade #2

Grandes ataques (inclusive bancos) exploram falhas do Top 10

👉 nada “sofisticado”
👉 só mal feito bem explorado

---

🔥 Curiosidade #3

OWASP não é só Top 10

Eles têm:

• guias de código seguro
• ferramentas
• labs
• projetos específicos

---

⚠️ O maior erro do dev sênior

“Eu já vi de tudo… isso não me pega.”

---

💥 Realidade

• Sistemas antigos + integração moderna = risco novo
• Código legado + API aberta = superfície de ataque gigante

---

🧠 Mentalidade que muda o jogo

Antes:

“Funciona?”

Agora:

“É seguro?”

---

💀 Frases pra carregar com você

“Se entra sem controle… vira comando.”

“Se está no código… não é segredo.”

“Você não precisa ser hackeado… para estar vulnerável.”

---

☕ Conclusão — o choque final

OWASP não é um framework.

Não é uma ferramenta.

Não é modinha.

---

👉 É um espelho.

Ele mostra:

• onde você erra
• como você pode cair
• e como evitar o pior

---

🎯 Fechamento estilo Bellacosa

“O mainframe não vai te salvar.”

“O COBOL não vai te salvar.”

(pausa)

“Mas o conhecimento… pode.”

 

 

Bellacosa Mainframe DEVSECOPS na pratica

🔥💀 SEU COBOL NO IBM z17 ESTÁ SEGURO… OU SÓ AINDA NÃO FOI TESTADO POR UM ATACANTE?

Do RACF ao DevSecOps: o guia definitivo de Application Security para quem mantém sistemas que não podem falhar

---

☕ INTRODUÇÃO — A VERDADE QUE QUASE NINGUÉM FALA

Se você trabalha com COBOL no mainframe, provavelmente já ouviu isso:

“Mainframe é seguro por natureza.”

👉 Não.
Ele é resiliente, confiável e robusto — mas segurança de aplicação não vem de fábrica.

E aqui vai o ponto que muda tudo:

💣 Os mesmos erros que derrubavam sistemas há 20 anos… continuam sendo explorados hoje.

---

🧠 UM POUCO DE HISTÓRIA (ANTES DO “CYBER” EXISTIR)

Nos tempos de:

• cartões perfurados
• terminais 3270
• batch noturno

Segurança era baseada em:

👉 controle físico e acesso restrito

💬 Easter egg:

“Se você não estava na sala do mainframe… você não atacava o sistema.”

Hoje?

👉 qualquer API exposta conecta seu sistema ao mundo.

---

🔐 O NASCIMENTO DA SEGURANÇA NO MAINFRAME

Ferramentas como o RACF surgiram para resolver:

• quem pode acessar
• o que pode acessar
• quando pode acessar

👉 Foi o início do que hoje chamamos de Identity & Access Management

---

💣 O PROBLEMA MODERNO

Hoje temos:

• APIs
• integração com cloud
• microservices
• mobile apps

👉 E seu COBOL continua sendo o backend crítico

---

💥 Resultado:

O mainframe virou alvo indireto

---

🔥 OWASP — O MANUAL DO ATACANTE

A OWASP lista as principais vulnerabilidades.

E aqui vai o choque:

👉 SQL Injection, XSS e falhas de validação continuam no topo.

💬 Curiosidade:

A lista de 2007 é assustadoramente parecida com a atual.

---

💣 SQL INJECTION NO COBOL (SIM, EXISTE)

❌ Código vulnerável

EXEC SQL
  SELECT * FROM USERS
  WHERE NAME = :WS-NAME
END-EXEC

Se WS-NAME vier contaminado…

💥 você abriu a porta

---

💣 Ataque clássico

' OR '1'='1

👉 bypass de autenticação

---

✅ Correção

• validar input
• restringir caracteres
• checar SQLCODE

---

💬 Insight:

“O problema não é o SQL… é confiar no input.”

---

🌐 XSS — O ATAQUE QUE NÃO ESTÁ NO COBOL… MAS TE AFETA

Você pode pensar:

👉 “isso é problema de frontend”

Errado.

Se seu sistema:

• expõe API
• retorna dados sem sanitização

💥 você participa do ataque

---

🧪 SAST, DAST E SCA — OS 3 PILARES

🔍 SAST (Static Analysis)

Analisa código sem executar

👉 detecta:

• lógica insegura
• SQL injection

---

🌐 DAST (Dynamic Analysis)

Testa sistema rodando

👉 simula atacante real

---

📦 SCA (Dependências)

👉 detecta vulnerabilidades em:

• bibliotecas
• frameworks
• integrações

💣 Insight:

“Seu código pode estar perfeito… mas sua dependência pode te comprometer.”

---

🔐 SECRETS — O ERRO QUE MAIS DERRUBA EMPRESA

❌ Clássico COBOL

MOVE "PASSWORD123" TO WS-PASS

💥 vazamento garantido

---

✅ Correto

• usar RACF
• usar controle externo
• nunca hardcode

---

💬 Easter egg:

“Se está no código… já não é segredo.”

---

🔄 DEVSECOPS NO MAINFRAME

Antes:

👉 segurança no final

Hoje:

👉 segurança no início

---

🔥 Pipeline moderno

código → scan → teste → deploy → monitoramento

---

Mesmo no mainframe, isso já é realidade com:

• pipelines CI/CD
• integração com APIs
• automação de testes

---

🧱 CICS — O PONTO CRÍTICO

💣 Problema

MOVE DFHCOMMAREA TO WS-DATA

👉 sem validação

---

✅ Correção

• validar tamanho
• validar conteúdo
• tratar EIBCALEN

---

🗄️ DB2 — ONDE O DADO VIRA RISCO

• SQL mal construído
• input não validado
• retorno ignorado

👉 tudo isso vira vulnerabilidade

---

💥 ERROS QUE CAUSAM INCIDENTES

• input sem validação
• senha em log
• dependência vulnerável
• falta de monitoramento

---

💬 Curiosidade:

Grandes incidentes não acontecem por falhas complexas…
mas por erros básicos ignorados.

---

🧠 MENTALIDADE — O QUE SEPARA OS PROFISSIONAIS

Dev comum:

👉 “funciona”

Dev sênior (seguro):

👉 “resiste a ataque”

---

☕ PARA PENSAR NO CAFÉ

“Você não precisa ser hackeado para estar vulnerável…
basta não testar.”

---

🧪 PASSO A PASSO PRÁTICO (APLICÁVEL HOJE)

1. Valide TODO input
2. Remova secrets do código
3. Revise SQL crítico
4. Analise dependências
5. Teste como atacante
6. Automatize segurança

---

💣 REALIDADE FINAL

Seu sistema pode:

• processar milhões de transações
• rodar há décadas
• nunca ter caído

👉 e ainda assim estar vulnerável

---

💬 FRASE FINAL

“Mainframe não é seguro por ser forte…
é seguro quando você fecha as portas certas.”

---

🚀 CONCLUSÃO

Application Security não é moda.
Não é ferramenta.
Não é opcional.

👉 É responsabilidade de quem escreve código.

---

Se você domina COBOL e agora entende segurança…

🔥 você não é mais só dev
👉 você é um guardião de sistemas críticos