Todos os desenvolvedores desejam criar software program seguro e confiável. Eles devem se sentir orgulhosos de lançar seu código com whole confiança de que não introduziram nenhum ponto fraco ou antipadrão em seus aplicativos. Infelizmente, a maior parte dos desenvolvedores não escreve seu próprio código atualmente. 96% de todo o software program contém alguns componentes de código aberto, e os componentes de código aberto representam entre 70% e 90% de qualquer software program moderno. Infelizmente para nossos desenvolvedores preocupados com a segurança, a maioria das vulnerabilidades modernas vem desses componentes de software program.
À medida que novas vulnerabilidades surgem e são relatadas publicamente como Vulnerabilidades e Exposições Comuns (CVEs), as equipes de segurança não têm outra escolha a não ser pedir ao desenvolvedor que refatore o código para incluir diferentes versões das dependências. Ninguém fica feliz com essa situação, pois ela bloqueia novos recursos e pode ser enlouquecedor reverter versões de componentes e torcer para que nada quebre. Os desenvolvedores precisam de uma maneira de rapidamente determinar se um componente que desejam usar tem uma vulnerabilidade conhecida antes de fazer uma solicitação pull.
Felizmente para desenvolvedores e equipes de segurança, agora é mais fácil e rápido do que nunca verificar CVEs localmente, automaticamente e antes de qualquer commit ser feito.
Compreender o que está no seu código antes de ser confirmado
A análise de código-fonte (SCA) surge principalmente em discussões sobre listas de materiais de software program (SBOMs) e em conversas sobre conformidade, e normalmente muito mais tarde do que a própria escrita do código. Com o GitGuardian Software program Composition Evaluation (SCA), os desenvolvedores verificam problemas diretamente de seu terminal em qualquer ponto de seu trabalho, graças ao ggshield, a CLI do GitGuardian. Com um comando rápido, os programadores podem testar se uma versão específica de uma dependência introduz uma vulnerabilidade conhecida. O GitGuardian mostrará até mesmo se uma correção está disponível.
Neste exemplo, adicionamos um requisito para a biblioteca `go-getter` e especificamos a versão 1.7.1. Pode haver muitos motivos pelos quais um desenvolvedor teria usado essa versão, como copiar de um tutorial mais antigo ou de uma postagem on-line que explica a funcionalidade dessa biblioteca. Uma simples varredura SCA mostra que esta versão não apenas introduziria uma vulnerabilidade conhecida, mas também há uma correção disponibilizada na versão 1.7.4.
 |
| ggshield, a CLI do GitGuardian, realizando uma varredura SCA para encontrar uma vulnerabilidade no código. |
Verifica automaticamente apenas as novas alterações
Embora a verificação native de CVEs em nosso código seja muito poderosa, ainda é um processo handbook. Os humanos são ótimos em serem criativos, mas não somos ótimos quando se trata de executar repetidamente cada etapa de um processo, especialmente as tediosas. É bom que todo desenvolvedor tenha uma plataforma de automação completa construída diretamente em sua ferramenta favorita de gerenciamento de controle de origem, Git Hooks.
A varredura do GitGuardian SCA pode ser acionada automaticamente na fase de pré-confirmação ou pré-envio do fluxo de trabalho do Git. O momento ideally suited para detectar qualquer problema no código é antes que ele chegue ao histórico do seu projeto. Se nunca for confirmado, é provável que uma verificação de segurança não detecte posteriormente um problema no pipeline ou na produção de CI/CD. Embora novos CVEs surjam diariamente, devemos fazer tudo o que pudermos para garantir que não estamos adicionando CVEs conhecidos ao nosso código.
 |
| Um gancho git pré-commit que executa automaticamente o comando ggshield sca scan pre-commit |
Digitalizando apenas o escopo correto de trabalho
Você verá no exemplo do git hook que estamos usando o comando `ggshield sca scan pre-commit` em vez de `ggshield sca scan all` como usamos no exemplo do handbook. Esta variante na varredura SCA limita a varredura apenas ao diretório de trabalho atual, ou seja, apenas às alterações que foram feitas desde o último commit. Dessa forma, se houver vulnerabilidades na base de código que ainda não possam ser resolvidas, elas não bloquearão suas alterações. Apenas novos problemas com dependências serão identificados e o commit será interrompido.
 |
| O git hook pré-commit encontra uma vulnerabilidade crítica quando um commit é tentado, impedindo que o código seja adicionado ao projeto. |
Neste exemplo, não apenas o commit não acontece, mas a mensagem do GitGuardian nos informa que há uma correção disponível em uma versão posterior. Tudo o que nosso desenvolvedor precisa fazer é alterar um caractere no arquivo identificado, salvá-lo e então ele poderá fazer o novo commit com sucesso.
 |
| Um commit bem-sucedido assim que o código for atualizado. |
Mudar para a esquerda significa resolver problemas mais cedo
Embora a segurança exija toda a organização, equipar sua equipe de desenvolvimento com as ferramentas certas para encontrar e resolver problemas de segurança antecipadamente pode eliminar muitas dores de cabeça posteriormente no processo de entrega de software program. Quanto mais próximo da produção você encontrar um problema, mais caro se tornará sua correção. É por isso que disponibilizamos o GitGuardian SCA como um Git Hook pré-commit, para que cada desenvolvedor possa evitar adicionar uma vulnerabilidade conhecida ao pipeline e, eventualmente, à produção.
O GitGuardian SCA está disponível para um teste gratuito de 2 semanas após uma rápida conversa com nossa equipe. SCA é apenas uma das preocupações abordadas pelo conjunto de produtos do GitGuardian. Também integramos uma gama de ferramentas de segurança, incluindo Detecção de Segredos, Monitoramento Público, Segurança de Infra como Código e Honeytoken.
