Suporte Cyclonedx – Comunidade de Dev

Esta é a Parte 3 da série SBOM de postagens de blog, pois ainda não havia apoio em Raku para nenhum dos padrões do SBOM, era uma pergunta para qual padrão eu deveria estar desenvolvendo: SPDX 3.0.1 ou CyclonedX 1.6. Para o bem ou para o mal, selecionei o CyclonedX porque foi recomendado (obrigado Salve!) E porque tinha uma especificação melhor legível / navegável. Porque a implementação disso exigiria muita leitura e navegação! SBOM :: Cyclonedx Então, até o final de junho, comecei a trabalhar nisso, e a primeira versão do SBOM :: CyclonedX foi enviada em 7 de julho. Com a versão 0.0.15 carregada no outro dia. Acabou sendo uma das maiores distribuições únicas em que já trabalhei: 125 classes (espalhadas por 51 arquivos), 51 enumes e 25 subconjuntos, criados por mais de 5000 linhas de código e documentação embutida, resultando em mais de 4400 linhas de documentação de marcação. Mas por que tantas aulas? Um SBOM não é realmente um hash de escalares, matrizes e hashes? Recursivamente? Na verdade, é. Mas, para ser um SBOM válido, todos os tipos de restrições se aplicam à maioria dos campos, como um valor inteiro maior que 0. Ou entre 0 e 6. Ou um valor numérico entre 0 e 1. E esses são apenas valores numéricos. Fica muito mais complicado para cordas. Então, que maneira mais fácil haveria em Raku para ter essas restrições automaticamente verificadas por restrições de enum, subconjunto e classe? Além disso, é quase impossível adicionar funcionalidade personalizada a partes específicas de um hash. E alguma funcionalidade personalizada seria necessária e permitiria muito mais flexibilidade com a criação de ferramentas de introspecção. Por isso, optei pela criação de uma classe para cada parte do padrão CyclonedX 1.6 que não era um valor numérico ou string simples. Isso também permitiu mais reutilização interna, pois algumas classes são na verdade atributos de mais de uma outra classe. Eu também queria um bom erro de relatórios sobre SBOMs inválidos. Portanto, em vez de um único erro em uma parte do hash do SBOM abortando o processo de validação, eu queria que esses erros fossem coletados e produzidos no final (muito parecido com as preocupações com o tempo de compilação na linguagem de programação Raku). E como um bônus, dessa maneira pude colocar a documentação dos campos no SBOM como o declarador bloqueia no código -fonte e gerar a maior parte da documentação a partir disso. Por exemplo: #| Fornece informações adicionais sobre um BOM. classe SBOM :: Metadata faz sbom { #| A data e a hora (registro de data e hora) quando o nascimento foi criado. tem dateTime $ .timestamp; #| O (s) ciclo de vida (s) do produto que esse nasceu representa. tem sbom :: lifecycle @.lifecycles; … Digite o modo de saída de tela cheia de tela cheia o #| Indica um tipo especial de comentário (o “Declarador Block”) que se liga ao próximo declaração. Neste exemplo: uma classe e dois atributos (tem). O atributo “Timestamp” aceita apenas os tipos de datetime, e o atributo “Lifecycles” aceita apenas os tipos de ciclo de vida SBOM ::. E é assim que você acaba com mais de 5000 linhas de código e documentação em linha. Embora qualquer distribuição Raku provavelmente use apenas um pequeno subconjunto da funcionalidade oferecida pelo padrão CyclonedX 1.6, decidi implementar tudo isso, para que não precise começar a adicionar coisas mais tarde. E permitirá que este módulo (e, portanto, Raku) seja usado para qualquer aplicação SBOM fora da Câmara de Echo Raku. O que aumentaria a chance de mais pessoas instalar Raku, apenas para poder usar esse aplicativo. enumes Os valores do tipo “enum”, conforme especificado na especificação CyclonedX, representavam um problema interessante. O padrão não apenas define as cordas, mas também tem algumas descrições associadas a elas. Descrições que eu obviamente queria ficar por perto para fins de documentação. E, embora possamos especificar blocos de declaradores para uma enumeração, é (atualmente) impossível especificar blocos declaradores para cada um dos valores possíveis (e provavelmente seria impraticável também). Por isso, optei pela criação de uma função de enumificação dedicada que poderia ser usada em uma classe, imitando assim uma enumeração real, mas que permite chamar. Que permite fazer: use sbom :: enums; Diga “$ _: \ n $ _. Why ()” com fase; # pré-construção: # BOM composto por informações obtidas antes de um processo de construção e # pode conter arquivos de origem e artefatos e manifestos de desenvolvimento. # O inventário pode precisar ser resolvido e recuperado antes do uso. Digite o modo de saída do modo de tela cheia e para facilitar a vida (e futuros mantenedores), coloquei todas as cordas e descrições da enum como arquivos de texto na seção “Recursos” da distribuição. Por exemplo, os textos de enum em fase vivem em “Recursos/Enums/Fase”: $ CAT Resources/Enums/Fase Design Bom produzido no início do ciclo de vida de desenvolvimento que contém um inventário de componentes e serviços propostos ou planejados para serem usados. O inventário pode precisar ser adquirido, recuperado ou com recursos antes do uso. O BOM pré-construção que consiste em informações obtidas antes de um processo de construção e pode conter arquivos de origem e artefatos e manifestos de desenvolvimento. O inventário pode precisar ser resolvido e recuperado antes do uso. … Digite o modo de saída do modo de tela completa Um formato realmente simples: a primeira linha é o nome da enumeração e todas as linhas até que uma linha vazia seja a descrição. Todos lidos no momento da compilação do módulo e depois integrados à classe de fase. Scripts A distribuição SBOM :: CyclonedX instala um script Cyclonedx que permite verificar a validade de um arquivo SBOM e/ou fazer certas seleções nelas e/ou mostrar o SBOM em código JSON, YAML ou RAKU normalizado. Provavelmente receberá mais argumentos, pois as pessoas encontrarão mais usos para isso. Na verdade, espero poder integrar os recursos do SBOM ao app :: rak em algum momento no futuro não muito distante. Por exemplo, se você quiser ver a lista de URLs de embalagem usados pela distribuição SBOM-RAKU, pode-se fazer: $ ciclonedx–Purls sbom-raku/.meta/fonte.cdx.json PKG: RAKU/CPAN: Timotimo/JSON :: fast@0.19 PKG. pkg: raku/zef: leont/yamlish@0.1.2 pkg: raku/zef: lizmat/identity :: utils@0.0.28 pkg: raku/zef: lizmat/purl@0.0.14 pkg: raku/zef: lizmat/ragus/rak: rak: raku/zef: lizmat/purl@0.0.14: pkg: raku/zef: lizmat/sbom :: ciclonedx@0.0.13 pkg: raku/zef: lizmat/sbom :: raku@0.0.10 pkg: raku/zef: lizmat/string :: utils@0.0.36 PKG. PKG: RAKU/ZEF: RAKU-COMMUNITY-MODULES/MIME :: base64@1.2.4 pkg: raku/zef: raku-community-modules/opensssl@0.2.5 pkg: raku/zef: raku-community-modules/uri ::5: code: PKG: raku/zef: rbt/net :: dns@1.4 Digite o modo de saída de tela cheia de tela cheia, o que fornece uma boa visão geral de todas as dependências diretas (e transitórias) da distribuição. Mas o que é um url de embalagem que você diz? Bem, isso é para a próxima parte desta série de postagens de blog! Conclusão Foi muito trabalho criar uma distribuição que possa lidar com toda a extensão da especificação CyclonedX 1.6. Tenho certeza de que os bugs serão encontrados e parece que uma versão 1.7 da especificação CyclonedX está ao virar da esquina (o que implicaria que o trabalho seja feito novamente no SBOM :: CyclonedX). Mas pelo menos as bases foram colocadas para poder lidar com SBOMs na linguagem de programação Raku.

Fonte