ATALAIAPágina inicial: um programa de segurança aplicacional contado como uma fábrica isométrica que envolve uma torre de vigia, a Atalaia, no seu centro. A liderança, na sala de negócio, lê o mercado e decide o que construir. Os product managers levam a ideia para uma sala de sprint planning e desenho, onde se debatem backlog, arquitetura e requisitos, e mesmo em frente uma sala de threat modeling junta planeamento, programadores e cyber. A linha propriamente dita começa na sala da toolchain, onde os programadores escrevem código com IDEs, agentes de IA e servidores MCP e enviam pequenas peças para o tapete. O controlo de versões divide-as em branches; o pipeline corre-as em runners que carregam actions e plugins externos. Um porto da cadeia de fornecimento traz de fora extensões de IDE, pacotes, actions e peças de registries externos, e o build cresce à medida que as dependências entram, junto ao fetch do registry interno alimentado pelas prateleiras do registry. Análises e um auditor de pipeline CI/CD verificam o build, que depois para nas prateleiras DEV e PROD. Os dev leads aprovam e etiquetam a release e alinham com infra e cloud antes de fazer deploy para dev (testes unitários) e QA (testes funcionais). Um portão de staging deixa passar um build quase final para uma área de pentest onde atacantes tentam partir o ambiente. Depois a produção desbloqueia e é enviada para várias clouds, onde clientes satisfeitos a usam, black hats a sondam e white hats reportam o que encontram através de um programa de bug bounty. A maioria destes passos está ligada à torre de vigia, onde está a equipa de cyber.
Segurança aplicacional, da ideia à cloud.
Desenhamos, testamos e operamos o seu programa AppSec: threat modeling, pipeline e cadeia de fornecimento, pentest, bug bounty.
Tudo começa no mercado.
A liderança lê o mercado e decide o que construir a seguir para se manter à frente. Ainda sem código: uma ideia, uma aposta e o risco que o negócio está disposto a correr com ela. Os product managers levam-na desta sala.
PMs e engenheiros transformam a ideia num backlog.
Os product managers entram com a aposta. À volta da mesa de planeamento debatem execução, arquitetura, funcionalidades e requisitos, incluindo os não funcionais: quem pode usar, o que nunca pode vazar.
Ao lado do planeamento: o que pode correr mal?
Antes de qualquer coisa chegar à sala dos devs, cyber, product managers, project managers e security champions debatem o produto à mesma mesa. Saem com um modelo: o que pode correr mal, o que aceitamos e o que corrigimos antes de o código existir.
A linha começa nas secretárias dos programadores.
Os programadores escrevem o código com todas as ferramentas à mão: IDEs, agentes de IA, servidores MCP, extensões e pacotes locais. Pequenas peças saem das secretárias para o tapete. Monitorização de endpoints e uma firewall local dão à Atalaia visibilidade sobre tudo.
Cada peça é separada por branch.
O controlo de versões está no próprio tapete e divide o trabalho: feature branches, develop e main, cada uma com as suas regras de proteção.
Cada branch segue no pipeline.
As branches juntam-se num só tapete. Cada job é marcado com o runner que a sala das máquinas lhe atribui: partilhado, dedicado ou efémero. Qualquer um pode ser chamado. Os runners carregam actions e plugins que vêm de fora.
Metade do que envia chega por mar.
Extensões de IDE, pacotes locais, actions do pipeline e registries externos entram todos pelo mesmo porto. Basta um contentor adulterado. O build cresce à medida que os puxa, ao lado do que vem do seu próprio registry interno.
As análises correm, depois o próprio pipeline é auditado.
Análises automáticas verificam o que foi construído. Logo a seguir, um auditor de pipeline CI/CD verifica como foi construído: runners, tokens, permissões e actions fixadas.
A linha para na prateleira.
Os artefactos assinados chegam ao registry interno. O mesmo registry alimenta os pacotes internos que o próximo build vai buscar. Nada avança até alguém decidir fazer deploy.
Dev lead e infra enviam-no juntos.
O dev lead pede à infra uma janela de deploy para o pacote enviado para o registry. A infra dá luz verde; o dev lead vai buscá-lo à prateleira DEV, etiqueta v1.4.0 e entrega-o. A infra coloca-o no tapete de deploy.
Primeiro deploy: dev, depois QA.
Primeiro, o ambiente dev corre os testes unitários. Um controlo na linha verifica se passaram, e só então o QA corre testes funcionais e de regressão: funciona como previsto?
Passa um portão, depois alguém tenta partir.
Só um build quase final passa o portão de staging. Atrás dele, pentesters atacam de propósito uma cópia de staging do ambiente, com âmbito e regras de atuação. Cada falha vai para a Atalaia e é retestada após a correção.
Só agora prod desbloqueia.
Com QA e pentest a verde, a linha volta à prateleira PROD. O deploy em produção desbloqueia, com roles de deploy revistas, e camiões levam-no a todas as clouds que usa.
Os clientes usam. Os atacantes sondam.
Assim que está em produção, clientes satisfeitos entram na cloud de edge enquanto black hats martelam a secundária a partir de fora. Cada tentativa deixa rastos que a sua monitorização deve apanhar antes de virar notícia.
Pague a quem o avisa.
Os white hats testam as mesmas clouds, mas dentro de um âmbito e regras que publica. Reportam o que encontram através do programa; é triado, recompensado, corrigido e retestado, e cada relatório chega à Atalaia.
Todas as linhas vêm dar aqui.
A Atalaia, a torre de vigia, fica no meio da fábrica. Decisões de desenho, telemetria da toolchain, intel da cadeia de fornecimento, análises, o auditor de pipeline, registry, deploys, achados de pentest e relatórios de bug bounty reportam todos a ela.
As pessoas na torre.
Quem se senta onde, de que é responsável e como o trabalho é medido e financiado.
Vamos percorrer a sua linha em conjunto.
Uma chamada de 30 minutos. Mapeamos a sua linha numa página: onde é forte, onde é frágil e o que fazer primeiro.
Sem tabela de preços: cada projeto é definido na chamada.