3 dicas para um treinamento eficaz de segurança para desenvolvedores

“Esta é a era de ouro da segurança de aplicações”, afirma Jim Manico, fundador da Manicode Security e instrutor de programação segura, no episódio 26 do podcast The Secure Developer.

Há dez anos, diz Manico, o treinamento em segurança era “algo meio peculiar de fazer — uma atividade paralela”. Hoje, as ferramentas de avaliação estão mais maduras, há boas publicações sobre o tema que tornam o conhecimento mais acessível, e muitas pessoas inteligentes estão desenvolvendo aplicações seguras.

Viver na era de ouro não significa que o problema da segurança foi resolvido. Significa que sabemos o que precisa ser aprendido e temos os recursos e a determinação para oferecer essa educação.

Neste artigo, vamos explorar três dicas para aprimorar seu programa de educação em segurança para desenvolvedores e garantir que você aproveite todas as vantagens da era de ouro da segurança de aplicações.

1. Abra caminho para o aprendizado com requisitos de segurança claros

É impossível oferecer educação em segurança para desenvolvedores sem uma compreensão clara e compartilhada do que é segurança de aplicações.

Por isso, segundo Manico, definir requisitos de segurança claros é uma das medidas mais importantes que as empresas podem tomar para capacitar seus desenvolvedores. “Quero uma definição clara dos requisitos de segurança”, diz Manico, “para que todos entendam da mesma forma o que realmente é essa tal de segurança de aplicações”.

Embora muita gente recorra instintivamente ao OWASP Top 10, Manico recomenda evitá-lo. Em vez disso, ele recomenda o OWASP Application Security Verification Standard, que contém mais de 200 requisitos. Segundo Manico, a melhor parte desse padrão é que ele traz benefícios independentemente de até que ponto a equipe consiga aplicá-lo.

“Em linhas gerais”, diz Manico, “temos os requisitos definidos e traduzimos cada um deles para identificar onde ele se aplica no framework, o que precisamos fazer manualmente e onde podemos contar com ferramentas de terceiros”.

Mas, mesmo que as equipes não se aprofundem tanto, ainda há valor nisso. “Já vi pessoas definirem requisitos, nunca os lerem e, ainda assim, esse processo ser útil, porque os líderes técnicos conseguiram orientar os desenvolvedores líderes durante quatro ou cinco horas de conversa sobre o que é importante para a segurança”, diz Manico.

Assim, trabalhar nos requisitos de segurança ajuda a criar um consenso sobre o que desenvolvedores e equipes de segurança precisam fazer para alcançar certo nível de segurança de aplicações. Mesmo que as equipes não avancem tanto quanto poderiam, chegar a um consenso já ajuda muito.

“Independentemente de como você os definir, isso vai ajudar de alguma forma”, diz Manico.

2. Torne as equipes de desenvolvimento autossuficientes com um security champion

Há lágrimas em todas as formaturas do ensino médio e da faculdade, embora se formar seja justamente o objetivo. No fim, mesmo com toda a emoção, todo educador quer ver seus alunos se tornarem independentes, autossuficientes e bem-sucedidos.

O mesmo vale para a educação em segurança para desenvolvedores. As empresas fazem bem em contratar consultores e educadores externos de segurança, mas devem escolher profissionais que pensem desde o início em como as equipes vão trabalhar depois que o educador for embora.

Nick Vinson, líder de DevSecOps na Pearson, faz exatamente isso. Segundo Vinson, no episódio 84 do podcast The Secure Developer, o principal objetivo do seu trabalho é “fornecer à equipe as ferramentas e o conhecimento necessários para que ela seja autossuficiente”.

Para isso, a equipe de Vinson integra engenheiros de segurança experientes às equipes com as quais trabalha. Esses profissionais atuam como membros efetivos da equipe, com capacidade para implementar, testar e colocar mudanças em produção.

Enquanto fazem parte da equipe, esses especialistas realizam modelagem de ameaças para identificar riscos e vulnerabilidades de segurança. Também implementam testes de segurança automatizados no SDLC e, ao mesmo tempo, garantem, como diz Vinson, que “as equipes saibam o que fazer, em vez de apenas marcar itens em uma lista”.

Para consolidar esse novo conhecimento, o especialista integrado também prepara um security champion interno, além de oferecer trabalho e orientação. “Essa é nossa principal responsabilidade”, diz Vinson.

Ao integrar um engenheiro de segurança à equipe, Vinson alcança dois objetivos ao mesmo tempo: fortalecer mais rapidamente a segurança de aplicações e formar um security champion capaz de fazer com que as práticas de programação segura perdurem.

3. Conquiste credibilidade com os desenvolvedores para criar confiança

Muitas pessoas são céticas quanto à possibilidade de educar desenvolvedores sobre segurança. Será que eles não vão tratar a segurança como um exercício de marcar itens em uma lista, uma distração do trabalho principal?

Jet Anderson, engenheiro de segurança na Amazon, rebate sem rodeios no episódio 98 do podcast The Secure Developer: “Isso é uma bobagem — não acho que seja verdade nem um pouco”.

Ao contrário do que se costuma presumir, Anderson vê os desenvolvedores engajados com a segurança. “Vejo que os desenvolvedores se importam muito com a qualidade e querem fazer a coisa certa”, afirma Anderson. E a segurança é parte essencial de fazer a coisa certa.

Segundo Anderson, a distância entre desenvolvedores e engenheiros de segurança não se deve à apatia dos desenvolvedores, mas à falta de compreensão mútua.

“Não é que os desenvolvedores não se importem”, diz Anderson. “É que quem trabalha com segurança da informação nem sempre tem um conhecimento profundo de desenvolvimento de software. Por isso, pode não ter a credibilidade ou até mesmo a linguagem necessária para explicar o risco ou a falha com precisão”.

Como exemplo, Anderson usa o termo “vulnerabilidade”. Entre profissionais de segurança da informação, esse termo é comum e usado em vários contextos, mas os desenvolvedores talvez entendam melhor outra terminologia. Anderson diz que aquilo que os profissionais de segurança costumam encontrar poderia ser descrito melhor como defeitos; um defeito só deveria ser chamado de vulnerabilidade quando há um exploit para ele.

“Esses pequenos detalhes fazem parte da mudança cultural”, diz Anderson. Embora possam parecer insignificantes, mudanças de linguagem como essas, repetidas em vários contextos, podem criar muito mais oportunidades de entendimento compartilhado entre engenheiros de segurança e desenvolvedores. Com essa compreensão em comum, a educação de desenvolvedores pode ter muito mais sucesso.

Levando o shift left para a mente dos desenvolvedores

Shift left é a prática de tirar a segurança do fim do SDLC, onde tradicionalmente é aplicada, e levá-la para a esquerda, mais perto do início do ciclo. Mas, segundo Anderson, é possível ir ainda mais para a esquerda, antes mesmo da primeira etapa do SDLC. “Não consigo pensar em um lugar anterior ao cérebro de um desenvolvedor”, diz Anderson.

Organizações que querem adotar o shift left e integrar a segurança aos fundamentos do design de aplicações precisam considerar tanto o que está em jogo quanto os pontos de partida disponíveis. Muitos desenvolvedores podem se formar na faculdade ou obter uma certificação sem aprender nada sobre segurança. Se você quer adotar o shift left, a educação em segurança para desenvolvedores é essencial.

Assine hoje o podcast The Secure Developer e receba mais dicas de especialistas em segurança.