As equipes de segurança têm enfrentado desafios para acompanhar o ritmo do desenvolvimento de software. E continuam enfrentando obstáculos, como líderes que negligenciaram a importância da segurança no processo de desenvolvimento e a disparidade no número de desenvolvedores em relação aos profissionais de segurança. Com a chegada da IA, esse ritmo se intensificou ainda mais. A velocidade de desenvolvimento só tende a aumentar à medida que as empresas evoluem para níveis corporativos. Com isso, as ferramentas de segurança usadas para controlar os processos de desenvolvimento devem acompanhar esse crescimento.
As equipes de segurança de aplicações precisam gerenciar e priorizar vulnerabilidades de forma eficaz. Com as políticas de segurança do GitLab e nosso conjunto de ferramentas de segurança, as empresas podem promover a colaboração entre as equipes de AppSec e desenvolvimento, facilitando a detecção, triagem e remediação eficientes de vulnerabilidades. As políticas de segurança também oferecem um mecanismo para automatizar a conformidade de segurança e gerenciá-la em escala empresarial.
Embora a análise de mais possíveis fontes de vulnerabilidades aumente as chances de detecção precoce e resolução de problemas, o grande volume de descobertas pode sobrecarregar as equipes de AppSec. À medida que obtemos mais insights sobre vulnerabilidades por meio de análises adicionais, identificar o que requer ação imediata torna-se cada vez mais desafiador.
Processos de triagem para gestão de vulnerabilidades
Atualmente, existem algumas abordagens comuns para realizar a triagem de vulnerabilidades:
-
Common Vulnerability Scoring System (CVSS): o sistema comum de pontuação de vulnerabilidades oferece um método padronizado para avaliar a severidade da vulnerabilidade. Ao utilizar as pontuações do CVSS, as empresas podem priorizar as vulnerabilidades com base em seu possível impacto e alocar os recursos necessários adequadamente.
-
Pontuação baseada em risco: esse sistema permite que as empresas avaliem as vulnerabilidades com base na probabilidade de exploração e no possível impacto para os negócios. Ao considerar fatores contextuais, como o valor dos ativos, os recursos de agentes mal-intencionados e a prevalência de exploits, as empresas podem priorizar vulnerabilidades de forma eficaz.
-
Modelagem de ameaças: é uma abordagem que envolve identificar e avaliar possíveis ameaças a uma aplicação ou sistema. Ao realizar uma análise completa da arquitetura do sistema, do fluxo de dados e dos possíveis vetores de ataque, as empresas podem priorizar as vulnerabilidades com base em sua relevância em relação a ameaças prováveis. Essa abordagem ajuda a alocar recursos de forma eficaz, pois foca em vulnerabilidades com maior probabilidade de serem exploradas.
-
Business Impact Analysis (BIA): é uma técnica usada para avaliar o possível impacto das vulnerabilidades nas operações e objetivos empresariais. Envolve identificar ativos críticos, avaliar sua importância para a empresa e quantificar as possíveis consequências de um ataque bem-sucedido. Ao considerar o possível impacto financeiro, reputacional e operacional, as empresas podem priorizar as vulnerabilidades que apresentam os maiores riscos para suas funções essenciais de negócios.
Com a crescente proliferação de código gerado por IA, aumentam também as vulnerabilidades não intencionais que são introduzidas. Técnicas como essas são fundamentais para ajudar as empresas a fazer triagens e determinar quais questões devem ser priorizadas. Mas, afinal, como podemos aplicar essas estruturas conceituais no mundo real? Vamos entender melhor como colocar essas técnicas em prática.
Gestão de políticas de segurança
As políticas de segurança são a solução para transformar políticas e requisitos de conformidade de nível empresarial em diretrizes operacionais tangíveis, incorporadas às suas práticas de DevSecOps e ao ciclo de vida do desenvolvimento de software. Ao criar regras dentro das políticas de segurança do GitLab, as empresas podem definir critérios detalhados para a avaliação de vulnerabilidades, garantindo que apenas as descobertas passíveis de resolução sejam sinalizadas para maior atenção.
As políticas de segurança permitem implementar seus requisitos e melhores práticas de segurança e conformidade ao transformá-los em código. As políticas de execução de análise garantem que os scanners sejam executados em projetos específicos conforme suas necessidades e requisitos, assegurando que vulnerabilidades e exposições sejam detectadas antes do merge do código na produção.
Você também pode utilizar as políticas de aprovação de solicitação de merge para criar fluxos de trabalho personalizados para resolver vulnerabilidades. As políticas avaliam os resultados dos scanners de segurança e conformidade para impedir ou bloquear a fusão de merge requests, a menos que tenham sido devidamente revisadas e aprovadas com base nas regras definidas.
Ao adotar as políticas de aprovação de solicitação de merge e políticas de execução de análise, você adiciona uma camada de controle ao processo de desenvolvimento. Isso pode garantir que o código, escrito por humanos ou não, seja analisado automaticamente e que as violações de políticas incentivem a colaboração entre as equipes de engenharia e AppSec onde for mais aplicável.
Definir regras granulares nas políticas de aprovação de solicitação de merge
Para ir mais além, você pode definir regras granulares dentro das políticas de aprovação de solicitação de merge com base nos filtros e atributos compartilhados abaixo. Essas regras podem ajudar a identificar quais vulnerabilidades são mais relevantes e a destacar informações úteis:
-
Status da vulnerabilidade: as políticas de segurança podem ser aplicadas com base no status de uma vulnerabilidade, geralmente com foco nas recém-detectadas que precisam passar por triagem. Também é possível criar regras baseadas em vulnerabilidades previamente detectadas com uma severidade específica, ou incluir ou excluir vulnerabilidades que foram descartadas.
-
Branch: direcione a aplicação de regras apenas para branches específicos, como o branch padrão de projetos críticos ou qualquer branch protegido.
-
Correção disponível: filtre as descobertas das análises de dependência e de contêiner quando uma correção não estiver disponível. Frequentemente, elas dependem de mudanças upstream de terceiros e ainda não permitem uma ação direta. É possível criar e monitorar tíquetes a partir das vulnerabilidades com uma data de vencimento para resolvê-las assim que uma correção estiver disponível.
-
Falso positivo: quando os scanners do GitLab identificarem uma descoberta como falso positivo (em análises de contêiner e Dependency Scanning), esse estado será marcado na vulnerabilidade. As políticas de segurança podem então usar isso para filtrar falsos positivos na supervisão das políticas de segurança, permitindo que engenheiros de AppSec e desenvolvedores ignorem essas detecções e façam o merge do código sem interrupções. As vulnerabilidades continuarão disponíveis no relatório de vulnerabilidades, caso seja necessária uma análise mais aprofundada.
-
Tempo ou Acordo de Nível de Serviço (SLA): às vezes, vulnerabilidades de menor severidade podem ser toleradas pelas empresas por um tempo, mas devem ser planejadas e tratadas dentro de um SLA razoável. Com as políticas de segurança, você pode definir SLAs baseados na severidade de uma descoberta, como permitir que vulnerabilidades de severidade média sejam mescladas sem a necessidade de aprovação, com um SLA de 60 dias para resolução (que pode ser registrado em um tíquete de acompanhamento com data de vencimento). No entanto, se a vulnerabilidade ultrapassar o SLA de 60 dias, as solicitações de merge serão bloqueadas e a vulnerabilidade deverá ser resolvida.
Priorize descobertas críticas em toda a empresa
Uma abordagem comum para lidar com grandes volumes de vulnerabilidades é começar aos poucos, priorizando as descobertas mais críticas em toda a empresa. Um SLA de triagem de vulnerabilidades pode facilitar esse processo, definindo regras para tratar vulnerabilidades dentro de um SLA específico, com base na severidade. Confira abaixo uma demonstração rápida de como usar uma política de aprovação de solicitação de merge do GitLab para aplicar SLAs diferentes conforme o nível de severidade das vulnerabilidades. Nesse caso, se uma descoberta de alta severidade for detectada, as solicitações de merge não serão bloqueadas por 30 dias, permitindo que os desenvolvedores resolvam o problema dentro da janela do SLA.
Garanta a separação de funções
As políticas de segurança podem ser gerenciadas de várias maneiras, mas a melhor abordagem é criar um projeto isolado no GitLab, que garanta a separação de funções entre os profissionais de segurança e as equipes de desenvolvimento. As políticas são armazenadas em YAML. Essa abordagem de política como código fortalece sua equipe de segurança e oferece diversos benefícios, como um histórico no Git de alterações nas políticas para maior visibilidade, controle de versão que facilita a reversão de mudanças prejudiciais, supervisão e aprovações obrigatórias de alterações nas políticas (se necessário), auditabilidade por meio dos eventos de auditoria do GitLab e controles concretos que podem ser apresentados como evidências a auditores.
Conectando todos os pontos
Gerenciar o fluxo crescente de vulnerabilidades requer uma abordagem precisa que equilibre análises detalhadas com triagem e remediação eficientes. As políticas de segurança do GitLab são uma solução eficaz que facilita a colaboração, oferece liberdade na definição de regras de política personalizadas e viabiliza a operacionalização precisa dos requisitos de negócios e estruturas de conformidade. Com as ferramentas de segurança do GitLab e a aplicação de filtros e atributos personalizados, as empresas podem otimizar a gestão de vulnerabilidades e direcionar seus esforços para os riscos mais críticos. Isso não apenas fortalece sua postura geral de segurança, como também garante a conformidade com os requisitos de órgãos externos. Ainda que existam preocupações em relação ao código gerado por IA, os três pilares da segurança (pessoas, processos e tecnologia) permanecem firmes. Ao incorporar políticas de segurança em seus processos de negócios, você pode proteger sua empresa contra esses riscos.
Além de usar políticas de segurança para implementar políticas como código em grande escala, a plataforma DevSecOps do GitLab oferece um conjunto completo de ferramentas de segurança. Em nosso recente Relatório global de DevSecOps de 2023, 57% dos profissionais de segurança afirmaram usar seis ou mais ferramentas para o desenvolvimento de software, enquanto 69% expressaram o desejo de consolidar sua cadeia de ferramentas. A consolidação de ferramentas é prioridade para muitos CISOs, e o GitLab se destaca ao ajudar a reduzir a expansão da cadeia de ferramentas. Oferecemos as principais soluções para análise de segurança: Testes Estáticos de Segurança de Aplicações (inclusive para infraestrutura como código), detecção de segredos, Testes Dinâmicos de Segurança de Aplicações (inclusive para APIs), Dependency Scanning e segurança de API. Também facilitamos a gestão de vulnerabilidades para as equipes de AppSec, com relatórios dinâmicos de vulnerabilidades. Por fim, fechamos o ciclo de conformidade com estruturas de conformidade, relatórios de adesão e eventos de auditoria.
Saiba mais sobre como gerenciar a segurança de aplicações usando o GitLab.
Próximo artigo: Josh Lemos, Diretor de Segurança da Informação do GitLab, explica como resolver problemas comuns de segurança.