Imagine um dia na vida do Fábio, que Dev em uma empresa de SaaS...

Segunda-feira.

8:30: O Fábio que chega para trabalhar.

O celular já alertou que as 9 horas tem reunião!

O Fábio passa na máquina e pega seu café preferido, um capuccino com canela.

Entra na sala de reunião. O quadro branco ainda tem os rascunhos da semana passada e muita coisa que foi rabiscada, nem sequer foi possível começar...

Novas idéias, novas classes NodeJS que o pessoal estava bolando, alguns bugs, coisas do React e por aí vai...

Mal sentou na cadeira e já entra os gerentes.

O PO (Product Owner) chega e já entrega uma lista de coisas que o cliente pediu. O PM (Product Manager) já carregou uma tonelada de requisitos no Trello.

O Fábio rola a lista do Trello e ela e não termina mais, parece rolagem infinita. A coluna 'TO-DO' não pára de crescer e a 'DONE' continua a menor de todas.

Se tudo correr bem a reunião vai demorar 1h. O Fábio anota o que é mais importante, e parece que a reunião vai terminar mais ou menos nesse tempo. 

Termina a reunião e todos voltam para suas mesas. Ok, nada anormal nisso.

Fábio senta, coloca seu fone, faz um pull no Git e já começa caçar aquele bug que todo mundo está reclamando.

Chega meio-dia e o Fábio sai para almoçar com o pessoal. Hora de dar uma esvaziada, mindfulless.

Depois do almoço é hora de priorizar as features mais importantes e entregar aquilo o que o CS (Customer Success) está reclamando já faz uma semana

15hs: hora do break. Fábio já fez alguns commits de bugs, mandou alguns commits no master e o Jenkins fez deploy sem erros, nada de rollback....o dia está indo bem. 

18hs: "bora pra casa". O Fábio ganhou o dia. Corrigiu vários bugs, fez commit importantes e deploy.

Show! A aplicação está funcionando muito bem.

Mas quando sobre tempo para falar sobre segurança?

"Ah, primeiro vamos fazer funcionar depois a gente vê isso".

Novamente, nada de errado com essa afirmação. Afinal o cliente está cobrando o CS, o pessoal do suporte também e o PM coloca pressão, porque já que não consegue mais sair as 18hs.

O problema é que esse "depois" nunca chega. Nada é feito sobre cibersegurança.

Talvez quando a empresa contratar uma consultoria, ou pior um ataque de Data Extrafiltration (vazamento de dados) acontecer na aplicação (bata 3 vezes na madeira).

Como responder essas peguntas...

Será que temos algum framework desatualizado na aplicação?

Será que alguém esqueceu algum acesso aberto na nuvem?

Estamos usando criptografia corretamente em nossa API ou integrações?

Será que alguém esqueceu algum snapshot ou backup sem criptografia na AWS ou Azure?

Nossas configurações na AWS ou na Azure estão de acordo com melhores práticas de segurança?

Estamos em compliance com a LGPD para proteção de dados?

O cenário acima nós já vimos acontecer numa empresa de software SaaS. O pessoal tem uma aplicação incrível, mas um certo dia o banco de dados vazou por um simples erro de configuração.

Pode ser que sua rotira seja completamente diferente, mas serve para ilustrar uma coisa:

Na maioria das vezes segurança sempre fica para depois.

Mas então o que fazer? No mínimo automatizar o que conseguir.

Aí que entra a verificação de vulnerabilidades automatizada e checklist de compliance.

O pessoal de Dev tem razão...fazer scanning na aplicação e checklist de segurança na nuvem, é chato, demorado, repetitivo, ninguém gosta e ninguém tem tempo para fazer isso.

"Deixa isso para o pessoal de security ou para o sysadmin".

É algo raro, mas muito raro, uma startup ou empresa de SaaS ter um cara dedicado para cibersegurança.

Ok, mas digamos que você já faz alguma varredura de segurança no código ou QA (Quality Assurance), então também deveria integrar uma camada de scan de vulnerabilidades no seu workflow e checklist de compliance na AWS ou Azure. Se você usa Jenkins, por exemplo...você pode integar facilmente!

Isso é tão sério que o Google lançou em julho/2018 o 'Container Registry Vulnerability Scanner' que é um scanner de vulnerabilidades conhecidas em imagens no nível de container no Google Cloud...então fazem scanning a cada deploy da imagem.

É isso que o ScanX pode fazer no nível de aplicações.

Imagine que a cada deploy para produção, o ScanX fizesse uma varredura de vulnerabilidades de forma automática? Ou a cada semana o ScanX fizesse um checklist de segurança na AWS ou Azure?

E se você usa Slack ou Jira pode integrar e receber as notificação ultra críticas de security, nada de alertas low ou medium, somente as High ou Critical Issues. Sua aplicação iria elevar o nível de segurança de forma rápida e sem parar seus jobs e sem impactar seu workflow de desenvolvimento.

Se você tem alguma ferramenta de analytics, o ScanX também pode mandar diretamente para seu analytics ingerir os alertas gerados.

Bom, isso é nossa visão do ScanX para DevOps...identificar falhas conhecidas e erros em configuração de forma automatizada, para seu time priorizar patching, ganhar tempo e todo mundo ir para casa no horário.

Se você já tem ou está pensando em ter um DevSecOps, então ter na sua stack uma camada Vulnerability Assessment é fundamental, o ScanX pode ajudar nisso!

Ah, se você leu até aqui e ainda acha que estamos falando bobagem, veja nosso post sobre o report do Gartner que está guiando a segurança em DevOps "10 Things to Get Right for Successful DevSecOps".

Bom trabalho!

ScanX Team.

PS: Veja também nosso FAQ completo para ter mais alguns insigts...

PS2: Se depois que você ler nosso FAQ e ainda achar que estamos falando balela...pode mandar um email e nos cobrar um cerveja!