Neste artigo, daremos sequência à série de publicações sobre o OWASP SAMM (Software Assurance Maturity Model), abordaremos a prática de segurança relacionada ao Build Seguro, dentro do domínio de Implementação.
Você também pode ouvir esse conteúdo:
Antes de entendermos melhor como funciona a prática de build seguro, é interessante aprendermos um pouco sobre o conceito. O termo build vem de “construir” ou seja no ambiente de desenvolvimento de aplicações “construção” do software. O processo de build é estruturado junto ao pipeline da aplicação.
É importante mencionar que manter um processo de build bem definido e executado de forma automatizada não só traz grandes vantagens no âmbito de segurança, mas também melhora e facilita o processo de desenvolvimento da sua aplicação. Com isso, traz vantagens como facilitar a instalação e atualização de novas features, incorporar funcionalidades adicionais, garantir uma manutenção mais rápida em casos de problemas, bugs e vulnerabilidades.
Build Seguro de acordo com SAMM
Agora vamos abordar como o SAMM avalia a maturidade de um build seguro e quais são os requisitos necessários para alcançar uma maturidade máxima no build de sua aplicação.
Segundo o SAMM, o Secure Build (SB) ou Build Seguro é a prática de construir softwares e aplicações de forma padronizada e repetível, com o uso de componentes seguros para auxiliá-lo.
O processo de build seguro é dividido em dois fluxos principais, o primeiro concentra-se em buscar maneiras por uma automação total de processo de build, incluindo verificações de segurança adicionais como SAST (Static Application Security Testing) e DAST(Dynamic Application Security Testing), com o objetivo de ter sinalizações mais rápidas em casos de regressões de segurança, garantindo um software mais robusto e seguro.
Já o segundo trata-se de reconhecer as dependências utilizadas nas suas aplicações, identificando possíveis vulnerabilidades e problemas, assim identificando dependências que possam causar algum impacto negativo na aplicação. Em um grau mais maduro são realizadas verificações de segurança em tempo de compilação, como, por exemplo, com o uso de ferramentas de análise de composição de software (SCA – Software Composition Analysis).
Processo de construção
A maturidade avança em conjunto com o grau de automação do seu processo de build, onde inicialmente tem uma parte do processo que precisa passar por um conjunto de instruções manuais. O nível máximo de maturidade é atingido quando todo seu processo de build e compilação são automatizados, passando por verificações de segurança realizadas durante a compilação do software.
Nível 1 de maturidade
Nesse primeiro nível de maturidade é esperado que o processo de build seja bem definido e estruturado, dividido em um conjunto de instruções claras, onde possam ser seguidas por uma pessoa ou ferramenta. Tal definição deve descrever o processo de “ponta-a-ponta”, com o objetivo de sempre produzir o mesmo resultado.
A definição deve ser armazenada e centralizada em um local específico e de fácil acesso para uma pessoa ou programa, inclusive deve ser sempre atualizada conforme o processo for evoluindo.
Nível 2 de maturidade
No segundo nível é esperado que o seu processo de compilação seja totalmente automatizado, sem a necessidade de uma intervenção humana. O objetivo é que as compilações possam ser executadas a qualquer momento, possibilitando a redução da probabilidade de erro humano.
Com o processo sendo automatizado, os cuidados devem ser ainda maiores, pois a confiança aumenta e se não houver uma atenção necessária, poderá gerar futuros problemas. O processo sendo automatizado pode exigir acesso a credenciais e segredos necessários para construir o software, portanto, mantenha os segredos criptografados e controle o acesso com base no princípio do menor privilégio.
É importante mencionar que o processo de build deve ser seguido de acordo com as melhores práticas orientadas pelos fornecedores.
Por fim, adicione verificações de segurança automatizadas como ferramentas SAST no pipeline, com o intuito de deixar a sua automação mais robusta e com uma camada a mais de segurança.
Nível 3 de maturidade
No último nível de maturidade é esperado que suas verificações de segurança sejam adequadas e bem definidas, bem como seus critérios mínimos para aprovação na compilação (a aprovação na compilação pode ser específica para uma aplicação, assim podendo ter perfis de criticidade de acordo com impacto que a aplicação tem para o negócio). Não tenha medo de “travar” a compilação caso algum critério pré-definido não seja alcançado. Em alguns casos, esse critério pode ser definido pela criticidade da vulnerabilidade. Um exemplo: sempre que for identificado uma possível vulnerabilidade crítica, a pipeline “trava” e é “destravada” assim que a vulnerabilidade é corrigida ou definida como falso positivo, e esse processo também é conhecido como “Quality Gate”. No entanto, certifique-se de que primeiro esses casos sejam explicitamente aprovados e tenha registros e sua ocorrência junto com uma justificativa.
Por fim, ao menos uma vez ao ano deve-se selecionar e configurar ferramentas para avaliar cada aplicação em relação aos seus requisitos de segurança, como com o uso de métodos de modelagem de ameaças.
Dependências de Software
Em um nível mais baixo de maturidade, você mantém um registro de suas dependências e seus CVEs identificados e avança à maturidade conforme avalia constantemente suas dependências, identificando possíveis problemas que as dependências possam causar na aplicação. No nível máximo de maturidade, o seu processo de compilação passa por validações de segurança automatizadas.
Nível 1 de maturidade
Neste primeiro nível é esperado que você tenha um registro de todas as dependências usadas em todo o ambiente de produção. Esse registro muitas vezes é chamado de lista de materiais (BOM).
Reúna as seguintes informações sobre cada dependência:
- Onde é usado ou referenciado;
- Versão usada;
- Licença;
- Informação da fonte (link para o repositório, nome do autor, etc.);
- Status de suporte e manutenção da dependência;
- Verifique os registros para descobrir quaisquer dependências com vulnerabilidades conhecidas e atualize ou substitua-as de acordo.
Com essas informações consolidadas, é importante validar se alguma dependência de sua aplicação é afetada por algum determinado CVE (Common Vulnerabilities and Exposures). Em casos de complicações, substitua a dependência por outra que tenha o mesmo resultado.
Nível 2 de maturidade
Em um segundo nível de maturidade é esperado que você tenha uma avaliação das suas dependências usadas. Assim definindo critérios de usabilidade, com grau de aceitação para projetos, equipes ou organização.
Revise as dependências usadas regularmente para garantir que:
- As dependências permaneçam licenciadas corretamente;
- Não existam vulnerabilidades conhecidas e significativas que afetem suas aplicações;
- A dependência ainda seja ativamente suportada e mantida;
- Você esteja usando uma versão atual;
- Em casos de adição de uma nova dependência, deve haver uma razão válida para incluí-la na aplicação.
As dependências devem ser avaliadas constantemente, para casos de surgimento de novos CVEs, alterações de licença com possíveis impactos no uso legal de aplicativos ou identificação de dependências desnecessárias. Se algum desses cenários forem identificados, a equipe responsável pela dependência deve ser alertada.
É importante mencionar que existem boas práticas a serem seguidas, como o estudo e implementação do “proactive controls” da OWASP que contém medidas de segurança para uso de bibliotecas e dependências de terceiros.
Nível 3 de maturidade
Para atingir o último nível de maturidade é necessário que seu processo de compilação esteja conectado a um sistema ou ferramenta (como um SAST ou SCA, por exemplo). Para rastrear riscos de dependência de terceiros, mantenha uma lista de permissão de suas dependências e suas versões aprovadas, e “trave” a pipeline quando alguma dependência fora de sua lista tente ser compilada. Integre seu pipeline de compilação com esse sistema ou ferramenta para definir que sua compilação “trave” sempre que as dependências incluídas contiverem vulnerabilidades acima de um nível de criticidade definido, a menos que essa vulnerabilidade seja avaliada como um falso positivo ou o risco seja explicitamente aceito, a compilação não deve ser “destravada”.
Por fim, estabeleça processos de divulgação de vulnerabilidade com os fornecedores de suas dependências, incluindo SLAs para correção de problemas.
O que podemos concluir
Na prática de desenvolvimento seguro é importante ter um processo de Build bem definido, com uma automatização robusta que deve ser acompanhada de perto, definindo regras que garantam que sua aplicação não seja compilada caso alguma regra seja violada. Lembre-se que, quanto antes uma vulnerabilidade ou problema na aplicação for descoberto, menos tempo e custo será preciso para corrigi-la.
Também é importante manter as dependências de suas aplicações e suas listas de dependências atualizadas e seguir as melhores práticas de utilização e reavalie o uso delas caso surja algum empecilho que possa impactar o negócio ou aplicação.
Série artigos SAMM
- Governança segundo SAMM: Estratégias e Métricas em Segurança de Aplicações
- Governança segundo SAMM: Políticas e Conformidades em Segurança de Aplicações
- Governança segundo SAMM: Educação e Orientação em Segurança de Aplicações
- Design segundo SAMM: Modelagem de Ameaças em Segurança de Aplicações
- Design segundo SAMM: Requisitos de Segurança em Segurança de Aplicações
- Design segundo SAMM: Arquitetura Segura em Segurança de Aplicações
- Implementação segundo SAMM: Build Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Deploy Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Gestão de Defeitos em Segurança de Aplicações
- Verificação segundo SAMM: Análise de Arquitetura em Segurança de Aplicações
- Verificação segundo SAMM: Testes Orientados a Requisitos em Segurança de Aplicações
- Verificação segundo SAMM: Testes de Segurança em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Incidentes em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Ambientes em Segurança de Aplicações
- Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações
