Language
Country/Area
No result found
Os perigos ocultos do software de código aberto: seu código já está em risco?
No atual ambiente de desenvolvimento de software, o software de código aberto (OSS) se tornou a primeira escolha para muitas empresas e desenvolvedores. Mas você sabia que usar software de código aberto também traz riscos potenciais? A análise de composição de software (SCA) é um método que ajuda os desenvolvedores a revisar os componentes de código aberto incorporados em seu código para verificar se estão atualizados, a ter vulnerabilidades de segurança ou cumprir os requisitos de licenciamento.
O software de código aberto é amplamente favorecido devido à sua flexibilidade e custos reduzidos de desenvolvimento, mas os riscos por trás dele são frequentemente negligenciados.
Contexto do risco
Essa abordagem para desenvolver software a partir de diferentes componentes se tornou cada vez mais comum desde o final da década de 1990, com o surgimento do software de código aberto. Essa abordagem divide a complexidade de uma grande base de código em partes menores para aumentar a flexibilidade e acelerar o processo de desenvolvimento. No entanto, os riscos representados pelo software de código aberto aumentam claramente à medida que mais componentes são usados, e esses riscos podem ser categorizados em cinco categorias principais:
- Controle de versão: riscos de novas versões
- Segurança: Riscos de vulnerabilidade em componentes - Vulnerabilidades e Exposições Comuns (CVE)
- Licenciamento: Riscos dos requisitos legais para propriedade intelectual
- Desenvolvimento: Riscos de compatibilidade entre a base de código existente e o software de código aberto
- Suporte: Risco de documentação incompleta e componentes desatualizados
A análise automatizada e o gerenciamento de riscos estão se tornando uma necessidade para organizações que fazem uso extensivo de componentes de código aberto.
Como funciona o SCA
Os produtos SCA geralmente funcionam assim: primeiro, o mecanismo de varredura examina o código-fonte do software e os artefatos relacionados usados para compilá-lo, identificando os componentes de código aberto usados e suas versões. Essas informações são então armazenadas em um banco de dados, formando um catálogo de componentes de código aberto usados. Este catálogo é então comparado com um banco de dados de vulnerabilidades de segurança conhecidas, requisitos de licenciamento e versões históricas.
Por exemplo, ao realizar a detecção de vulnerabilidades de segurança, essa comparação geralmente é feita com vulnerabilidades de segurança conhecidas rastreadas no National Vulnerability Database (NVD). Alguns produtos podem usar bancos de dados de vulnerabilidades proprietários adicionais para suas verificações. Para fins de propriedade intelectual e conformidade legal, os produtos SCA extraem e avaliam os tipos de licenças usadas por componentes de código aberto. Esses resultados geralmente são fornecidos aos usuários em diferentes formatos digitais e incluirão avaliações de risco e recomendações de requisitos legais com base nas necessidades de diferentes produtos, especialmente requisitos para licenças de compartilhamento fortes ou fracas.
Os resultados também podem incluir um Manifesto de Componente de Serviço (SBOM), que detalha os componentes de código aberto usados no aplicativo de software e suas propriedades.
Uso do SCA
Como o SCA afeta diferentes funções organizacionais, diferentes equipes aproveitam esses dados, geralmente dependendo do tamanho e estrutura da organização. Os departamentos de TI usam a SCA para implementar e operar a tecnologia, e as principais partes interessadas incluem o Diretor de Informações Chefe (CIO), Diretor de Tecnologia (CTO) e Chefe da Enterprise Architect (EA). Dados de segurança e autorização são frequentemente usados pelo Diretor de Segurança da Informação (CISO) para gerenciar riscos de segurança, enquanto o Diretor de PI/Conformidade se concentra em riscos de propriedade intelectual. Dependendo dos recursos do produto SCA, essas ferramentas podem ser usadas diretamente no ambiente de desenvolvimento integrado (IDE) do desenvolvedor ou podem ser usadas como uma etapa necessária no processo de controle de qualidade do software.
Vantagens e desvantagens do SCAEm alguns países, como os Estados Unidos, a necessidade de geração de SBOM é obrigatória para garantir a segurança do software entregue por fornecedores a agências governamentais.
A automação é a principal vantagem dos produtos SCA. Quando os desenvolvedores usam e integram componentes de código aberto, não há necessidade de trabalho manual adicional. Isso também inclui o tratamento automatizado de referências indiretas a outros componentes de código aberto. No entanto, os produtos SCA atuais também apresentam algumas fraquezas importantes, como: o processo de implantação é complexo e demorado, podendo levar meses para estar totalmente operacional; cada produto usa sua própria biblioteca de componentes OSS proprietária, o tamanho e a cobertura dessas bibliotecas são limitadas; As taxas podem variar amplamente; e os dados de vulnerabilidade geralmente são limitados a relatar apenas aquelas vulnerabilidades que foram formalmente relatadas no NVD.
Além disso, os produtos SCA muitas vezes carecem de orientação automatizada, recomendações inadequadas sobre ações a serem tomadas em dados em relatórios e pouca orientação sobre requisitos legais para licenças OSS detectadas.
Nesse contexto, você também está pensando em como gerenciar de forma mais eficaz os riscos potenciais do software de código aberto e proteger seu código contra ameaças?
