v2.0.0 · Passo 3

Perfis de carga: DL_TECH_VULNERABILIDADE_V3 e DL_TECH_CMDB_V2

Novos perfis de carga do APEX para alimentar as colunas Tier-1 criadas no capítulo 11 — sem sobrescrever DL_TECH_VULNERABILIDADE_V2/DL_TECH_CMDB_V1, que continuam servindo a v1.3.0 em produção.

Status: mapeamento confirmado contra export real, perfis ainda não criados

O mapeamento abaixo foi conferido campo a campo contra um export real de Tenable/ServiceNow (arquivos em ampmInsights_V1_Cliente/Artefatos/, só linhas AM...) — não é suposição. O que falta é a parte que não é scriptável: criar os dois perfis de carga de fato no App Builder (Shared Components → Data Load Definitions), seguindo o roteiro da seção 4.

1. Por que perfis novos, não sobrescrever os antigos

Mesma regra já usada na v1.3.0 (ver capítulo 10): não alterar DL_TECH_VULNERABILIDADE_V2/DL_TECH_CMDB_V1 até o fluxo novo estar validado, para não quebrar a carga que já roda em produção no cliente. Os perfis novos são adicionais às colunas de sempre — não removem nenhum mapeamento existente.

2. RAW_JSON continua pendente (de propósito)

Este passo não popula RAW_JSON. O motivo: o Data Load do APEX só leva pra tabela as colunas que ele mapeia — os campos Tier 2/3 do export (que nunca ganharam coluna tipada) não chegam nem perto da tabela por este caminho. Popular RAW_JSON de verdade (a linha completa do export, todas as ~99/41 colunas) depende da tabela de staging (próximo item da Fase 1 no TASKS.md) — lá sim a linha inteira do CSV existe antes de qualquer filtro de coluna, e um `JSON_OBJECT(*)` sobre o staging resolve isso corretamente.

3. Mapeamento — DL_TECH_CMDB_V2 (12 colunas novas)

Coluna de origem exatamente como aparece no export ServiceNow real:

Coluna no export ServiceNowColuna destino (v2.0.0)Observação
install_statusINSTALL_STATUStexto direto
life_cycle_stage_statusLIFE_CYCLE_STAGE_STATUStexto direto
assigned_to (ou assigned, se assigned_to vier vazio)ASSIGNED_TOnos ativos AMPM amostrados, os dois vinham vazios com frequência — não é bug, é lacuna do cadastro de origem
attestation_scoreATTESTATION_SCOREnumérico direto
attestation_statusATTESTATION_STATUStexto direto (ex.: "Ainda não revisada")
attestedATTESTED_FLAGvem como Verdadeiro(a)/Falso(a) — mesma convenção já usada em SOX/COFRE/TENABLE/SIEM no capítulo 10; converter para 1/0
attested_byATTESTED_BYtexto direto
u_fim_do_suporteU_FIM_DO_SUPORTEformato confirmado: DD-MM-YYYY (ex.: 01-07-2029) — configurar a máscara de data do Data Load Wizard como DD-MM-YYYY
locationLOCATIONtexto direto
asset_tagASSET_TAGtexto direto
u_server_roleU_SERVER_ROLEtexto direto

4. Mapeamento — DL_TECH_VULNERABILIDADE_V3 (23 colunas novas)

Coluna no export TenableColuna destino (v2.0.0)Observação
definition.cveDEFINITION_CVElista separada por vírgula, texto direto
definition.descriptionDEFINITION_DESCRIPTIONtexto direto (CLOB)
definition.solutionDEFINITION_SOLUTIONtexto direto (CLOB)
definition.synopsisDEFINITION_SYNOPSIStexto direto
software_vulnsSOFTWARE_VULNStexto bruto (CLOB) — não fazer parsing agora, formato não é JSON válido (ver gap analysis seção 2.4)
definition.cvss3.base_scoreDEFINITION_CVSS3_BASE_SCOREnumérico direto
definition.cvss3.base_vectorDEFINITION_CVSS3_BASE_VECTORtexto direto
definition.cpeDEFINITION_CPEtexto direto
definition.epss.scoreDEFINITION_EPSS_SCOREnumérico direto
definition.vpr.drivers_on_cisa_kevCISA_KEV_FLAGconfirmado: vem como texto true/false (não aninhado) — converter para 1/0
definition.exploited_by_malwareEXPLOITED_BY_MALWARE_FLAGconfirmado: texto true/false — converter para 1/0
definition.exploited_by_nessusEXPLOITED_BY_NESSUS_FLAGconfirmado: texto true/false — converter para 1/0
portPORTnumérico direto
asset.operating_systemASSET_OPERATING_SYSTEMtexto direto; asset.operating_systems (plural) tem o mesmo conteúdo nos exemplos vistos — usar o singular como principal
last_fixedLAST_FIXEDdata/timestamp direto
time_to_fixTIME_TO_FIXnumérico direto
vuln_sla_dateVULN_SLA_DATEdata/timestamp direto
definition.patch_publishedPATCH_PUBLISHEDcorreção: o nome real no export tem o prefixo definition., diferente do que constava antes
definition.vulnerability_publishedVULNERABILITY_PUBLISHEDcorreção: idem, prefixo definition.
sourceSOURCE_SCANtexto direto
scan.idSCAN_IDtexto direto
scan.targetSCAN_TARGETtexto direto

5. Como criar os perfis no App Builder

Não é scriptável de forma confiável para esta aplicação (ver decisão registrada no capítulo 8/histórico do projeto sobre export de página) — precisa ser feito manualmente no App Builder:

  1. App Builder → Application 100 → Shared Components → Data Load Definitions.
  2. Selecione DL_TECH_CMDB_V1 (ou DL_TECH_VULNERABILIDADE_V2) e use Copy (não edite o original) — renomeie a cópia para DL_TECH_CMDB_V2 (ou DL_TECH_VULNERABILIDADE_V3).
  3. Na cópia, adicione os campos novos da tabela da seção 3 (ou 4) — cada campo novo mapeado para a coluna de destino correspondente.
  4. Para os campos flag (ATTESTED_FLAG, CISA_KEV_FLAG, EXPLOITED_BY_MALWARE_FLAG, EXPLOITED_BY_NESSUS_FLAG): configure a transformação de valor (Value Map / Column Transformation) Verdadeiro(a)/true → 1, Falso(a)/false → 0.
  5. Para U_FIM_DO_SUPORTE: configure a máscara de data como DD-MM-YYYY.
  6. Salve e teste com uma planilha pequena (5-10 linhas de ativos AM...) antes de rodar a carga completa.

6. Como validar

Depois de rodar uma carga de teste pequena:

Confirma que os campos novos vieram preenchidos
SELECT asset_name, definition_cve, definition_cvss3_base_score,
       cisa_kev_flag, exploited_by_malware_flag
FROM V_26AI_TECH
WHERE definition_cve IS NOT NULL
FETCH FIRST 5 ROWS ONLY;

Se vier linha com DEFINITION_CVE preenchido e CISA_KEV_FLAG/ EXPLOITED_BY_MALWARE_FLAG como 1 ou 0 (nunca texto), os perfis estão funcionando.