Está confiante nas suas capacidades de desenvolvimento - suficientemente confiante para saber que as aplicações que criou não estão completamente isentas de falhas de segurança e configuração. Também pesquisou o profundo ecossistema de ferramentas de análise disponíveis e talvez tenha ficado sobrecarregado com o enorme volume de escolha. Qual é o "portfólio" certo de ferramentas de segurança de aplicativos de código aberto para identificar vulnerabilidades em suas dependências, configurações de Infraestrutura como Código (IaC), contêineres e muito mais?
Para o colocar no caminho certo, cobriremos 10 categorias essenciais de ferramentas de análise de código e segurança e recomendaremos 9 projectos OSS, com apenas as informações essenciais de que necessita para começar:
- Como é que essa verificação ajuda a segurança da sua aplicação.
- Que projeto de código aberto pode instalar e como executá-lo.
- Algumas alternativas (quando disponíveis) que pode escolher.
Com isso, terá um caminho sem barreiras para analisar as suas aplicações em busca de problemas críticos de segurança no código e nas configurações da nuvem. O que há para não adorar?
Bem, a parte da configuração e gestão não é só rosas - mas falaremos disso mais tarde.
O que é necessário
Basta trazer a sua estação de trabalho local, quer seja um computador de secretária ou um portátil - não importa se está a utilizar o macOS, o Windows ou o Linux.
Um ambiente de desenvolvimento é opcional, mas recomendado. Para executar este conjunto de ferramentas de análise de código aberto, terá de instalar muito software que poderá não querer no seu sistema operativo de base, exigindo maiores actualizações, poluindo o seu preenchimento automático e fixando-o a ferramentas específicas que poderão não funcionar em todos os seus projectos. Um ambiente de desenvolvimento coloca em contentores e isola, até certo ponto, todas as suas ferramentas específicas de desenvolvimento do resto do seu SO.
Felizmente, tem à sua disposição algumas ferramentas de código aberto excelentes:
- Com Docker, pode criar um novo contentor barebones com o nome
devenv-01assim:docker run --name devenv-01 -it ubuntu:24.04 sh - Com Daytonaque vem com muitas "pilhas incluídas" para fluxos de trabalho de desenvolvimento:
daytona create --code - Ou com o Distrobox, que integra qualquer distribuição Linux no seu terminal, permitindo-lhe instalar software
O melhor de um ambiente de desenvolvimento é que, quando terminar uma determinada "pilha", pode eliminar o contentor em segurança sem afetar a sua estação de trabalho.
#1: Gestão da postura de segurança na nuvem (CSPM)
Como é que o CSPM ajuda a segurança das aplicações?
O CSPM ajuda-o a melhorar a segurança e a conformidade dos seus ambientes de nuvem. Ao monitorizar continuamente as suas aplicações e os respectivos serviços a montante em relação às melhores práticas da indústria e às suas políticas internas, as ferramentas CSPM avaliam os problemas, dão-lhes prioridade com base na sua criticidade e oferecem recomendações para a correção. Com o CSPM, o utilizador assume uma maior responsabilidade pelas linhas de base e pelos guardrails que o impedem, a si ou a outros, de promover aplicações vulneráveis para produção, ao mesmo tempo que elimina configurações incorrectas e funções de utilizador demasiado permissivas.
Instale e execute o seu projeto OSS CSPM: CloudSploit
Para instalar o CloudSploit, primeiro precisa do Node.js para descarregar as suas dependências e executar o motor.
git clone https://github.com/aquasecurity/cloudsploit.git
cd cloudsploit
npm install
Em seguida, é necessário configurar o CloudSploit com permissões de leitura para a sua conta na nuvem, com suporte para AWS, Azulejo, GCPe Oráculo. Siga as instruções para seu provedor de nuvem, usando o config_example.js ficheiro como seu modelo, para criar um config.js com todos os detalhes necessários para executar o seu primeiro diagnóstico completo e obter resultados em JSON.
./index.js --collection=file.json config.js
#2: Análise da composição de software (SCA) de dependências de código aberto
Como é que o SCA ajuda a segurança das aplicações?
É inevitável que as suas aplicações tenham uma grande árvore de dependências de código aberto, desde a sua estrutura de IU até às bibliotecas auxiliares que utiliza num único LOC, como um validador de endereços de correio eletrónico. A SCA é como uma verificação de antecedentes da família alargada do seu código, identificando vulnerabilidades de segurança e problemas de licenciamento não uma vez, mas continuamente. Uma vez que as suas ferramentas SCA o notificam sobre novas vulnerabilidades e soluções, terá a certeza de que a sua cadeia de fornecimento de código aberto continua a ser um auxiliar, e não um obstáculo, à produtividade.
Instale e execute os seus projectos OSS SCA: Syft + Grype
Para o SCA executado localmente, precisará do Syft para criar uma lista de materiais de software (SBOM) e do Grype para analisar a referida SBOM em busca de vulnerabilidades conhecidas. Uma vez que a mesma equipa cria o Syft e o Grype, eles suportam muitos métodos de instalação, mas recomendam os seus respectivos one-liners:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Com o Syft instalado na sua estação de trabalho local, pode criar um SBOM para o seu contentor, substituindo <YOUR-IMAGE> com uma imagem num registo de contentores configurado ou num diretório local.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
Acabará por ter um sbom.syft.json no seu diretório de trabalho, que pode depois introduzir no Grype.
grype sbom:path/to/syft.json -o json
Em seguida, o Grype imprime um resumo da vulnerabilidade no formato abaixo, incluindo detalhes de gravidade e informações sobre correcções conhecidas, que pode utilizar para orientar o seu processo de priorização e correção.
{
"vulnerability": {
...
},
"relatedVulnerabilities": [
...
],
"matchDetails": [
...
],
"artifact": {
...
}
}
Alternativas e advertências
O Trivy é uma alternativa OSS sólida para SCA - não oferece paridade de funcionalidades 1:1 em todas as áreas, mas é mais do que suficiente para começar.
#3: Deteção de segredos
Como é que a deteção de segredos ajuda a segurança das aplicações?
Uma ferramenta de deteção de segredos analisa o seu código e configurações em busca de credenciais que não quer expor publicamente. Esses segredos podem incluir chaves de API, tokens de acesso a fornecedores terceiros, senhas para bancos de dados upstream, certificados, chaves de criptografia e muito mais, e uma vez que eles são enviados para um repositório público, você terá que passar por um processo doloroso para removê-los do seu histórico do Git - é melhor detectá-los cedo e tomar medidas antes de fazer o commit.
Instale e execute o seu projeto de deteção de segredos OSS: Gitleaks
Gitleaks procura nos seus repositórios a presença de segredos codificados, passados ou presentes, analisando os registos do Git. Os seus detetar identifica os segredos que já foram comprometidos, enquanto o comportamento proteger O comportamento verifica as alterações não comprometidas para evitar que cometa erros em primeiro lugar.
Para um controlo máximo, recomendamos a instalação do Gitleaks a partir da fonte.
git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build
Na primeira vez que executar o Gitleaks, pode criar um relatório de base para fornecer resultados apenas para a exposição de novos segredos.
gitleaks detect --report-path gitleaks-report.json
Com invocações subsequentes, deve fazer referência à sua gitleaks-report.json para verificar os logs do Git apenas para segredos adicionados desde que você criou o relatório de linha de base.
gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json
O seu resultados.json irá conter detalhes sobre o hash do commit e o autor de cada potencial fuga, ajudando-o a concentrar-se nas correcções.
Alternativas e advertências
Infelizmente, não existem muitas opções para além do Gitleaks. Outros projectos de deteção de segredos de código aberto já passaram anos desde o último commit - o que não inspira propriamente confiança para proteger as aplicações em que está a trabalhar atualmente. Se for um fornecedor de serviços, pode registar-se no programa de parceiros de deteção de segredos do GitHub, que identifica quando os seus utilizadores submetem acidentalmente os seus formatos de token secretos para um dos seus repositórios.
#4: Testes estáticos de segurança das aplicações (SAST)
Como é que o SAST ajuda?
O SAST é o pente fino das ferramentas de segurança de aplicações, analisando a sua base de código linha a linha para verificar se há falhas de sintaxe, estrutura ou lógica que possam deixar a sua aplicação vulnerável. Pense em ataques de injeção de SQL, oportunidades de cross-site scripting (XSS), buffer overflows e muito mais. Ao verificar as bases de dados populares de CVEs conhecidos, uma ferramenta SAST sólida dar-lhe-á a confiança de que não está a deixar grandes falhas de segurança em cima da mesa - e algumas até oferecem sugestões de correção automática para uma rápida correção.
Instale e execute o seu projeto OSS SAST: Semgrep
O Semgrep analisa o seu código, encontra erros e impõe padrões de código estabelecidos em cada invocação, com suporte para mais de 30 idiomas. Para simplificar, estamos focados no Semgrep CLI, que é apenas uma parte de um complexo ecossistema de produtos.
A maneira mais universal de instalar o Semgrep CLI é com Python/pip.
python3 -m pip install semgrep
Execute a sua primeira análise para criar um relatório de falhas e vulnerabilidades ao nível do código como um ficheiro JSON.
semgrep scan --json --json-output=semgrep.json
Alternativas e advertências
O mundo SAST está repleto de oportunidades - se o Semgrep não funcionar para si, veja algumas alternativas específicas de linguagem como Bandit (Python), Gosec (Go), ou Brakeman (Ruby on Rails) para começar.
#5: Testes dinâmicos de segurança das aplicações (DAST)
Como é que a DAST ajuda a segurança das aplicações?
Ao contrário do SAST, o DAST simula vulnerabilidades comumente exploradas contra seu aplicativo em um ambiente ativo. É menos sobre a sintaxe e a estrutura do código que escreveu e muito mais sobre a replicação das abordagens que um atacante pode adotar contra a sua implementação de produção. As ferramentas DAST verificam duas vezes os CVEs conhecidos em estruturas e bibliotecas que utiliza e testam se os utilizadores com sessão iniciada podem aceder a dados sensíveis devido a permissões quebradas ou a "combinações tóxicas" de várias vulnerabilidades que abrem a sua aplicação a consequências muito piores.
Instale e execute seu projeto OSS DAST: Núcleos
O Nuclei é um scanner de vulnerabilidades voltado para a comunidade que usa modelos para enviar solicitações para o aplicativo que você deseja proteger em execução em um ambiente local. É possível escrever modelos personalizados usando YAML, mas a comunidade do Nuclei também tem uma extensa biblioteca de modelos pré-configurados para testar em sua aplicação.
É necessário ter o Go na sua estação de trabalho local para instalar o Nuclei.
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
A partir daí, a maneira mais simples de executar o Nuclei é especificando um único destino - seu aplicativo sendo executado localmente em um ambiente de desenvolvedor - e aproveitando a biblioteca de modelos, que o Nuclei ativa por padrão.
nuclei -u localhost:5678 -je nuclei-report.json
Alternativas e advertências
O Zed Attack Proxy (ZAP) é um fantástico scanner mantido ativamente por uma equipa global de especialistas em segurança e programadores. No entanto, ao contrário de outros nesta lista, o ZAP é uma aplicação gráfica por defeito. Existem opções para utilizar o seu terminal, mas não são exatamente as mais amigáveis para os programadores em comparação com outros processos que seguiu até agora.
#6: Verificação da infraestrutura como código (IaC)
Como é que a verificação de IaC ajuda a segurança das aplicações?
Seu código é apenas metade da equação para chegar à produção - hoje, a maioria das equipes usa ferramentas de IaC como Terraform, CloudFormation e gráficos "básicos" do Kubernetes Helm para provisionar serviços em nuvem de forma declarativa, controlada por versão e repetível. Os scanners de IaC identificam vulnerabilidades nesses blueprints JSON ou YAML para evitar que você implante um estado inseguro na produção.
Instale e execute o seu projeto de digitalização OSS IaC: Checkov
O Checkov examina muitos tipos de código de IaC - configurações do Terraform, gráficos do Helm, arquivos do Docker e muito mais - em busca de configurações incorretas comuns e possíveis vulnerabilidades de segurança. Com mais de 1.000 verificações de política incorporadas para AWS, GCP e Azure, a ferramenta ajuda-o rapidamente a compreender os riscos e oportunidades actuais das suas implementações na cloud em poucos minutos.
A equipa recomenda a instalação local do Checkov através do gestor de pacotes do Python.
python -m pip install checkov
Pode então executar o Checkov no seu diretório de trabalho (ou noutro diretório onde tenha armazenado ficheiros IaC) e obter um ficheiro JSON como saída.
checkov --diretory . -o json
#7: Digitalização de imagens de contentores
Como é que a análise de imagens de contentores ajuda a segurança das aplicações?
Adoramos os contêineres porque eles abstraem muita complexidade, mas sempre que você cria uma imagem de contêiner, ela pode herdar vulnerabilidades de sua imagem de base ou dependências de pacote. Os scanners de imagem de contentor descobrem vulnerabilidades nas suas imagens de base e Dockerfiles, independentemente da profundidade da árvore de dependências, para evitar que implemente involuntariamente uma aplicação explorável.
E foi também assim que nasceram as vulnerabilidades das imagens de contentores.
Instale e execute o seu projeto de digitalização de imagens de contentores OSS: Trivy
O Trivy é um scanner de segurança versátil capaz de analisar as suas imagens de contentores em busca de vulnerabilidades conhecidas com CVEs, problemas de IaC e configurações incorrectas, a presença de segredos e muito mais. A equipa Aqua Security, que está por detrás do projeto Trivy de código aberto, mantém uma base de dados pública de informações sobre vulnerabilidades, recolhidas a partir de mais de uma dúzia de fontes de dados.
Em sintonia com os outros mecanismos de instalação recomendados até agora, recomendamos a utilização do script do Trivy para instalar diretamente a partir da versão mais recente do GitHub.
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.51.1
Por predefinição, o Trivy analisa imagens de contentores em busca de vulnerabilidades, configurações incorrectas e segredos em relação a qualquer imagem de contentor que especifique, com resultados no formato JSON padrão.
trivy image --format json --output trivy-result.json <YOUR-IMAGE>
Alternativas e advertências
Se tem estado a acompanhar, já tem o Grype instalado na sua estação de trabalho local a partir da secção anterior sobre SCA, e funciona muito bem para analisar imagens de contentores com um SBOM criado pela Syft. Se estiver na AWS, este é outro lugar onde o Amazon Inspetor pode ser útil, como "dois pássaros, uma pedra".
O Amazon Inspetor também é uma opção, mas com duas grandes ressalvas - primeiro, só funciona com implementações AWS e, segundo, não é um software de código aberto como o resto das nossas recomendações, o que significa que tem novos custos mensais.
#8: Verificação de licenças de fonte aberta
Como é que a verificação de licenças de código aberto ajuda a segurança das aplicações?
A legalidade da utilização de software de código aberto nos seus produtos comerciais não é algo que se verifique uma vez com as equipas jurídicas ou de conformidade e se esqueça. Os projectos de OSS alteram as licenças com mais frequência do que possa imaginar, obrigando-o a pagar por uma versão empresarial, a procurar uma alternativa ou a abrir parte do seu código privado. Os scanners de licenças identificam as alterações e ajudam-no a passar pelas auditorias de segurança com uma lista de materiais de software (SBOM) pronta a utilizar.
Instale e execute o seu projeto de verificação de licenças OSS: Syft
Tal como aconteceu com o Grype no último passo, já tem o Syft instalado na sua estação de trabalho local e pode até ter um SBOM existente a partir da configuração da sua integração SCA com o Grype. Se ainda não tiver, pode criar rapidamente uma nova referenciando uma imagem de contentor de um registo configurado ou um caminho na sua estação de trabalho local.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json
Dependendo da complexidade da sua imagem e da profundidade das dependências, pode obter um ficheiro SBOM com alguns milhares de linhas. Dentro de toda essa saída JSON, você está procurando dentro do artefactos para a matriz licenças de cada pacote e dependência em que a sua imagem de contentor se baseia.
{
"artifacts":[
{
"id":"cdd2655fffa41c69",
"name":"alpine-baselayout",
"version":"3.4.3-r2",
"type":"apk",
"foundBy":"apk-db-cataloger",
"locations":[
…
],
"licenses":[
{
"value":"GPL-2.0-only",
"spdxExpression":"GPL-2.0-only",
"Type":"declared",
…
Com estes detalhes num único SBOM, poderá analisar as suas obrigações de licenciamento para detetar alterações que possam ter de ser feitas a jusante ou migrações para as quais se deve começar a preparar. Terá também um recurso de referência para a próxima auditoria de segurança a que for sujeito.
Alternativas e advertências
O Trivy, mencionado pela primeira vez na secção anterior, tem uma funcionalidade de análise de licenças que lhe apresenta resultados opinativos sobre o risco associado aos projectos na sua árvore de dependências de código aberto.
#9: Deteção de malware
Como é que a deteção de malware ajuda a segurança das aplicações?
Os scanners de malware ajudam-no a identificar uma ameaça que tem crescido nos últimos anos: malware injetado em pacotes de dependências por atacantes. A recente tentativa de backdoor do zx é um exemplo fantástico - e assustador. Os scanners de malware detectam estes ataques à cadeia de fornecimento de software antes mesmo de fundir o seu código, para evitar que tenha de efetuar correcções sensíveis ao tempo e dispendiosas quando o CVE se torna público.
Instale e execute o seu projeto de deteção de malware OSS: Phylum
As ferramentas CLI da Phylumpermitem-lhe submeter os seus lockfiles à sua API para análise de dependências, o que difere ligeiramente das outras ferramentas open-source que recomendamos aqui - a análise não acontece na sua estação de trabalho local. Em vez disso, é necessário registar uma conta no Phylum para autenticação com o seu serviço.
Comece por instalar o Phylum localmente.
curl https://sh.phylum.io | sh
Em seguida, registe a sua conta e execute a sua primeira análise - o Phylum deverá identificar o ficheiro de bloqueio que está a utilizar.
phylum auth register
phylum auth login
phylum init
phylum analyze --json
A análise do Phylum fornece um resultado abrangente, começando com um verdadeiro ou falso com base no facto de o seu projeto passar a verificação de malware do Phylum. Sob a matriz de rejeições para cada dependência, encontrará uma descrição detalhada da vulnerabilidade e conselhos de correção da comunidade OSS. Isto permite-lhe agregar os resultados dos seus testes SAST, DAST e SCA, permitindo-lhe compreender quais as vulnerabilidades que se devem às suas dependências e quais as que estão diretamente incorporadas no código que escreveu.
{
"is_failure": true,
"incomplete_packages_count": 2,
"help": "...",
"dependencies": [
{
"purl": "pkg:npm/next@13.5.6",
"registry": "npm",
"name": "next",
"version": "13.5.6",
"rejections": [
{
"title": "next@13.5.6 is vulnerable to Next.js Server-Side Request Forgery",
"source": {
"type": "Issue",
"tag": "HV00003FBE",
"domain": "vulnerability",
"severity": "high",
...
#10: Deteção de fim de vida útil (EOL)
Como é que a deteção de tempo de execução EOL ajuda a segurança da aplicação?
Quanto mais frameworks, bibliotecas e tempos de execução incluir na sua aplicação, mais oportunidades existem para que seja perigosamente utilizado contra versões desactualizadas ou dependências não mantidas. Isso é especialmente crítico para tempos de execução diretamente expostos à Internet pública. Os detectores de tempo de execução EOL lêem sua árvore de dependências por meio de lockfiles - mesmo aqueles em contêineres - para alertá-lo com bastante antecedência para que você possa se preparar para atualizações ou migrações.
Instale e execute o seu projeto OSS: endoflife.date
endoflife.date é uma base de dados de informação EOL sobre mais de 300 ferramentas e plataformas, muitas das quais são essenciais para o funcionamento e segurança da sua aplicação. Em vez de ter que explorar sites de documentação obscuros ou vasculhar listas de discussão para descobrir quando uma versão específica de sua dependência deixa de ser mantida, você pode rapidamente colocar datas em torno das atualizações necessárias para priorizar seus esforços no futuro.
A forma mais fácil de descobrir dados EOL é explorar o site, prestando especial atenção às suas linguagens de programação, bases de dados, estruturas, ferramentas de implementação e CLIs para serviços em nuvem.
Como desenvolvedor, você pode querer uma abordagem mais centrada na CLI para explorar dados EOL para seus principais tempos de execução e bibliotecas -endoflife.date tem uma API simples que gera dados JSON, que você também pode anexar a um arquivo local para referência futura.
curl --request GET \
--url https://endoflife.date/api/nginx.json \
--header 'Accept: application/json' \
>> eol.json
Um novo problema: gerir todos os seus dados de digitalização de código e de segurança de aplicações
Se você seguiu até aqui, você construiu um conjunto de ferramentas úteis de código de código aberto e ferramentas de verificação de configuração. Está pronto para começar a executá-las em seus projetos e branches armazenados localmente para obter melhores garantias de segurança pré-commit. Toma lá, desloca-te para a esquerda!
No entanto, o seu futuro não é instantaneamente perfeito. Este novo conjunto de ferramentas tem um grande senão: as suas ferramentas não falam em conjunto, e apenas em torno da sua aplicação.
Continua a ter de pagar:
- Configurar individualmente cada ferramenta. Tomemos uma opção simples, como uma lista de permissões de determinados diretórios ou dependências que você não quer se incomodar em verificar, pois eles não são relevantes para a segurança do seu ambiente de produção. Terá de aprender os argumentos de cada ferramenta CLI lendo a documentação e testando, o que lhe rouba tempo valioso daquilo que realmente quer fazer: implementar correcções.
- Executar cada scanner em cada repositório e ramo. Mesmo que tenha um único repositório e dois ramos-
principaledev-são quase 20 operações para verificar as vulnerabilidades. Idealmente, está a executar estes scanners antes de efetuar alterações a um controlo remoto, o que significa muitas operações repetidas ao longo do dia.
Há algumas maneiras de simplificar isso, é claro. Você pode escrever um script para encadear esses scanners de código aberto para serem executados manualmente ou como um gancho Git pré-commit. Isso economiza tempo no terminal, mas apenas gera uma saída JSON mais rápida - você ainda está no gancho para entender o quefoi alterado e se ainda pode enviar as suas alterações e (finalmente) criar o seu pull request. - Percorrer enormes matrizes JSON para obter informações. Essas ferramentas geralmente produzem resultados com milhares de linhas. A abrangência é boa, mas quem é que tem tempo para explorar dezenas ou centenas de potenciais problemas de segurança, na esperança de compreender cada um deles suficientemente bem para perceber a sua gravidade?
Com o tempo, vai precisar de uma forma mais intuitiva de ler os resultados do que linhas não formatadas de JSON, como importar para o Google Sheets ou criar uma aplicação simples para visualizar os resultados. - Compreender o que mudou entre as execuções. A análise de segurança tem dois objectivos. Em primeiro lugar, para o ajudar a identificar problemas existentes no seu código e configuração. Segundo, para evitar que introduza novas vulnerabilidades à medida que constrói. Se não conseguir perceber rapidamente se corrigiu uma determinada vulnerabilidade ou se não for notificado da introdução de uma nova vulnerabilidade no seu código, todo este esforço é uma perda de tempo.
Uma opção é incrementar ou marcar a hora dos ficheiros JSON de saída e, em seguida, utilizar ferramentas CLI para os comparar.diff ficheiro1.json ficheiro2.jsoné uma óptima ferramenta autónoma, ou pode experimentar ogit diff --no-index file1.json file2.jsonpara ficheiros não confirmados no seu repositório Git. - Agregar, armazenar e partilhar dados para análise a longo prazo. Como dissemos anteriormente, a análise de segurança é uma operação contínua, não um item pontual na sua lista de tarefas. Além disso, os resultados dos seus esforços de análise não devem ficar trancados na sua estação de trabalho local - os seus colegas vão querer saber quais as vulnerabilidades mais relevantes para o que construíram, mesmo que não tenham um conjunto de ferramentas semelhante a funcionar neste momento.
Terá de explorar plataformas de dados que coloquem toda esta informação num único local - mais uma peça de infraestrutura para alojar ou pagar. - Criar bilhetes no Jira ou no GitHub. Você ou um colega deve escalar cada vulnerabilidade identificada para um tíquete relevante que contenha todo o contexto necessário e possíveis correções. Esta é a única forma de garantir a transparência da segurança, fazer com que os seus colegas colaborem e criar o registo de auditoria que as suas normas de conformidade podem exigir. Nenhuma destas ferramentas suporta a integração com a sua plataforma de tickets, pelo que terá de criar estes tickets manualmente - e poderá haver dezenas, se não centenas, de tickets para analisar.
- Priorize os tickets com base na gravidade. Inundar os seus repositórios com tickets é um pesadelo para a gestão de projectos. É uma versão diferente, mas igualmente dolorosa, da fadiga de alertas: Como é que alguém sabe em que se deve concentrar primeiro? Se as suas ferramentas OSS não o puderem ajudar com a gravidade, terá de passar algum tempo a fazer essas determinações, o que pode envolver anos de conhecimento de segurança que não pode ser encurtado.
- Gerir o ciclo de vida de cada ferramenta OSS. Quer se trate de manter as suas ferramentas actualizadas, de tentar criar automação ou de inserir execuções e resultados no seu pipeline de CI/CD, é agora responsável pela eficácia a longo prazo do seu conjunto de ferramentas. Poderá ter uma postura de segurança melhor do que nunca, mas a que custo para a sua postura no mundo real?
- Preocupar-se e pensar no que acontecerá se o projeto perder o seu mantenedor. Se as suas dependências e tempos de execução podem chegar à EOL e criar problemas, o mesmo acontece com as ferramentas e plataformas de que o seu ambiente de desenvolvimento local depende. Infelizmente, os projectos de código aberto são frequentemente construídos com base em modelos de financiamento e de manutenção que não são sustentáveis a longo prazo. Ainda pode utilizar projectos estagnados ou abandonados no seu CLI, mas ao tentar melhorar a segurança da sua aplicação, estes não o ajudarão a descobrir novas vulnerabilidades ou métodos de ataque.
A conversa atual sobre ferramentas para programadores gira em torno de um único conceito: experiência do programador (DX). Quanto melhor a DX, maior a probabilidade de uma ferramenta ser integrada, usada, valorizada e defendida. E sejamos honestos - a DX deste kit de ferramentas de análise OSS gerido localmente não é particularmente boa. O processo e os dados são totalmente seus, mas com custos e compromissos de tempo excepcionais. Quanto está disposto a pagar pela segurança avançada das aplicações?
As ferramentas de segurança de código aberto são fantásticas - até criámos uma firewall de aplicação Web para proteger autonomamente as aplicações Node.js contra ataques comuns e críticos - mas para a verificação contínua da segurança e a correção de vulnerabilidades, tem de haver outra forma. Talvez até mesmo uma que seja construída em cima dessa fantástica base OSS.
Uma nova solução de segurança para aplicações: Aikido
O Aikido integra todos esses projectos de código aberto e muito mais.
Em vez de executar mais de 10 ferramentas sempre que se prepara para submeter as suas alterações mais recentes, só precisa de adicionar uma vez os seus repositórios, imagens Docker e fornecedores de serviços na nuvem ao Aikido para uma análise abrangente. O Aikido é executado automaticamente em segundo plano para análise contínua ou no seu pipeline CI/CD para recomendações direcionadas com cada pedido pull, protegendo-o de novas vulnerabilidades enquanto aponta as existentes que têm estado à espreita na sua base de código durante meses ou anos.
Melhor ainda, todos os resultados, o contexto e as possíveis correcções são agregados e armazenados num único local - o painel de controlo do Aikido - para que nunca tenha de se preocupar em analisar JSON, fundir várias fontes de dados ou pagar uma plataforma de gestão de dados dispendiosa para criar uma fonte de verdade. Até criámos regras personalizadas e "cola" especial entre estes projectos de código aberto para descobrir correlações e resultados que, de outra forma, exigiriam um investigador de segurança especializado interno.
O Aikido também se integra com as suas plataformas de gestão de tarefas e de mensagens, como o GitHub e o Slack, para criar tickets pré-geridos e priorizados. Com todo o contexto, a documentação e as correcções automáticas sugeridas, qualquer pessoa da sua equipa pode resolver o problema e acompanhá-lo até à correção de forma rápida e abrangente.
A segurança das aplicações estaria numa situação muito pior se não fossem estas ferramentas de código aberto e muitas outras. Isso é indiscutível. Mas só por causa da forma como as ferramentas de desenvolvimento funcionam - na sua estação de trabalho local, dentro do seu terminal - significa que são infinitamente flexíveis e inerentemente isoladas. O meme "funcionou na minha máquina" ainda se aplica aqui, apenas com um palavreado diferente:
Se estiver à procura de outra forma, que substitua toda a carga de construção deste conjunto de ferramentas de código aberto por uma plataforma que já está construída sobre os mesmos projectos, considere dar uma oportunidade ao Aikido gratuitamente.
Se você escolher a rota OSS, você tem nosso apoio e respeito... mas enquanto você está colocando novas ferramentas e dependências em seus fluxos de trabalho, você realmente deve deixar o Web Application Firewall do Aikido autonomamente e continuamente proteger suas aplicações Node.js até mesmo das vulnerabilidades mais cruéis. O melhor DX, afinal, é quando a ferramenta realmente faz todo o trabalho duro para você.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)