Documentação do Oracle Cloud Infrastructure

Principais Conceitos e Terminologia

As terminologias a seguir ajudam você a começar a usar o Application Dependency Management (ADM). A documentação do Oracle Cloud Infrastructure (OCI) fornece terminologia relacionada.

Dependência do Aplicativo

Um componente de software representado por um URL de pacote (purl) ou GAV (grupo Maven, artefato, coordenada de versão) que deve ser verificado quanto a vulnerabilidades em uma auditoria de vulnerabilidade.

Artefato

Um artefato é uma biblioteca, como um jar, que é produzido ou usado por um projeto de software.

As dependências de um projeto de software são especificadas em termos de seus artefatos. Alguns artefatos são produzidos por causa do processo de integração contínua do projeto. Eles estão localizados no repositório do projeto. Outros artefatos podem ser baixados de repositórios de terceiros e, por sua vez, têm artefatos dependentes. Portanto, um projeto tem um gráfico de dependências, algumas criadas pelo próprio projeto e outras fornecidas por colaboradores externos.

Ferramenta de integração contínua

A integração contínua é uma prática em que os membros de uma equipe de desenvolvimento compartilham e mesclam suas alterações em um repositório de controle de versão unificado. A prática é usada com testes automatizados e outras medidas de verificação para garantir a qualidade da versão unificada.

Uma ferramenta de integração contínua automatiza essa prática e fornece uma estrutura na qual os testes e as medidas de verificação são executados. O acesso a uma ferramenta geralmente é controlado por meio de permissões nas quais você pode conceder acesso de leitura e gravação a membros da equipe, colaboradores ou outras partes interessadas.

O Application Development Management suporta as seguintes ferramentas de integração contínua:
  • Pipelines de Build do OCI DevOps
  • GitHub Ações
  • GitLab Pipeline
  • Jenkins Pipeline
Base de Conhecimento

Uma base de conhecimento fornece acesso às vulnerabilidades dos serviços ADM. Quando você configura uma receita de remediação ou cria uma auditoria de vulnerabilidade, uma base de conhecimento deve ser especificada com a qual está associada. A base de conhecimento do ADM armazena detalhes de dependências de software para várias linguagens de programação e suas vulnerabilidades. A base de conhecimento foi aprimorada para armazenar os detalhes de classe e método de algumas vulnerabilidades Java.

Solicitação de Pull

Uma solicitação de pull, também conhecida como solicitação de mesclagem, é um meio comum de contribuir para um repositório de código-fonte que usa um sistema de controle de versão distribuído, como aqueles compatíveis com o ADM.

Por exemplo, um usuário cria uma solicitação de extração para informar outras pessoas sobre as alterações que foram enviadas para uma ramificação em um repositório. Quando usado com uma ferramenta de integração contínua, a solicitação de extração faz com que a ferramenta crie o projeto e verifique-o usando testes. Se a verificação for bem-sucedida, as alterações serão mescladas com o código-fonte do projeto existente.

Receita de Remediação

Uma receita de correção representa a configuração de um workflow, que consiste em uma sequência de quatro Estágios:

  1. Detectar
  2. Recomendar
  3. Verificar
  4. Aplicação

Normalmente, você cria uma receita de remediação correspondente à ramificação monitorada do Repositório que contém o projeto.

Uma Receita de Remediação tem um status, que deve ser:

  • Ativo
  • Criando
  • excluído
  • Exclusão
  • Falhou
  • Inativo
  • Precisa de Atenção
  • Atualizando
Execução de Remediação

Uma execução de remediação descreve a ação de executar uma receita de remediação, na qual cada estágio da receita de remediação é executado em sequência até que um estágio concluído seja atingido. Você pode acionar uma execução de remediação manualmente ou especificar que uma execução de remediação seja acionada quando uma nova vulnerabilidade for identificada.

Uma receita de remediação só poderá ser executada se estiver em seu status ativo.

Uma execução de remediação tem um status, que deve ser:

  • Aceito(s)
  • Cancelada
  • Cancelando
  • Criado em
  • Falhou
  • Em Andamento
  • Sucesso

O ADM suporta uma única execução por vez para uma receita.

Repositório

Um repositório de código é um local de armazenamento para o projeto de software. Geralmente inclui o código-fonte do projeto, metadados do projeto e outros artefatos dos quais o projeto depende. O acesso a um repositório geralmente é controlado por meio de permissões nas quais você pode conceder acesso de leitura e gravação a membros da equipe, colaboradores ou outras partes interessadas.

O Application Development Management suporta os seguintes repositórios:

  • OCI DevOps
  • GitHub
  • GitLab
Segredo

Um segredo é uma credencial como senha, certificado, chave SSH ou token de autenticação que você usa com os serviços do OCI.

Severidade

Gravidade refere-se ao impacto ou criticidade de uma vulnerabilidade, representada por diferentes valores.

Preparar
Um Stage descreve uma etapa em uma execução de correção. Os quatro estágios são:
  • Detectar: Detecte vulnerabilidades no aplicativo. Uma execução de remediação prosseguirá para o próximo estágio de uma execução de remediação se uma ou mais vulnerabilidades forem detectadas que excedem o limite de pontuação de CVE configurado. Se não houver nenhum, a execução da correção estará concluída e você poderá ver a saída da auditoria de vulnerabilidade.
  • Recomendar: Identifique as dependências de terceiros recomendadas que o aplicativo usa e abra uma Solicitação de Baixa Automática para propor essas alterações. Se for bem-sucedido, a execução da correção prosseguirá para o próximo estágio. Se ele não puder resolver novas versões de dependência para tratar as vulnerabilidades, a execução da correção será encerrada aqui, fornecendo os detalhes do que ele pode recomendar e as vulnerabilidades que não pôde resolver. Se o estágio falhar, a execução da remediação terminará aqui em um estado com falha.
  • Verificar: Verifique as alterações usando os testes especificados na ferramenta de integração contínua. A execução da correção prosseguirá para o próximo estágio se os testes forem bem-sucedidos.
  • Aplicar: Mesclar a solicitação de extração. Se a mesclagem falhar, a execução da correção terminará em um estado de falha.

Um Estágio tem um status, que deve ser:

  • Cancelada
  • Criado em
  • Falhou
  • Em Andamento
  • Sucesso
Vault

Um vault é uma entidade lógica na qual o serviço OCI Vault cria e armazena chaves e Segredos de forma durável.

vulnerabilidade
Uma vulnerabilidade é uma fraqueza ou um erro em um artefato de projeto, como uma dependência de aplicativo. Uma vulnerabilidade é uma generalização de uma falha de segurança da informação, como as descritas pelo sistema de CVE (Common Vulnerabilities and Exposures).

O National Vulnerability Database (NVD) fornece uma medida da gravidade de uma vulnerabilidade de software, usando o Common Vulnerability Scoring System (CVSS), variando de 0 a 10. O NVD suporta os padrões CVSS v2.0 e v3.0. Para obter mais informações sobre métricas de vulnerabilidade, consulte Banco de Dados de Vulnerabilidade Nacional. Juntamente com o CVSS, o ADM fornece seus próprios indicadores de gravidade, como Alto, Médio e Baixo. Vulnerabilidades com severidade Desconhecida não estão incluídas nas auditorias de vulnerabilidade.

Uma vulnerabilidade falso-positiva refere-se a uma vulnerabilidade detectada durante a criação da auditoria de vulnerabilidade, mas que não é considerada como afetando o aplicativo de acordo com os detalhes da dependência. O falso positivo é identificado usando o build de imagem nativa do Oracle GraalVM que captura o uso real do aplicativo no código por meio das classes e métodos do aplicativo e, em seguida, o compara com a base de conhecimento do Application Dependency Management.

Uma vulnerabilidade ignorada refere-se a uma vulnerabilidade detectada durante a criação da auditoria de vulnerabilidade, mas marcada como ignorada com base na configuração. A configuração é configurada para ignorar vulnerabilidades com base em padrões de exclusão ou valores de severidade máximos permitidos.

Auditoria de vulnerabilidade
Uma auditoria de vulnerabilidade contém as vulnerabilidades pelas quais um aplicativo é afetado por causa de suas dependências em um momento específico. Ele inclui informações resumidas sobre as quantidades e a severidade máxima das vulnerabilidades.

Uma auditoria de vulnerabilidade está associada a uma base de conhecimento.

Dados de Uso de Auditoria de Vulnerabilidade
A criação de auditoria de vulnerabilidade pode, opcionalmente, aceitar dados de uso como entrada ao criar uma auditoria de vulnerabilidade. Os dados de uso detalham todas as classes e métodos usados na imagem nativa GraalVM criada com base no aplicativo Java. O serviço ADM usa esses dados para identificar vulnerabilidades falso-positivas em que o aplicativo pode não ser vulnerável por causa do código vulnerável da dependência do aplicativo não estar sendo usado. O upload dos dados de uso é feito como um arquivo gzip no OCI Object Storage no formato JSON. Os dados são gerados pela ferramenta de inspeção GraalVM Native Image e Native Image.