Uma dúvida comum surge nas comunidades de ServiceNow:   "Change Models substituem os Change Types?".   A resposta curta é: Não. Eles trabalham juntos para oferecer flexibilidade sem perder a governança.   1. Change Types: O "O Quê" (Classificação) Os Change Types (Normal, Standard, Emergency) são a base do ITIL no ServiceNow. Eles servem para categorizar o risco e a urgência da mudança. Eles definem o comportamento padrão da plataforma. São usados para relatórios e auditoria (Compliance).   2. Change Models: O "Como" (O Guia de Jornada) Os Change Models são uma camada de abstração que apoia a criação da mudança. Em vez de o usuário ser forçado a um fluxo rígido baseado apenas no Tipo, o Modelo define: Transições de Estado: Quais passos são necessários para aquele cenário específico? Condições de Pré-preenchimento: O modelo pode já vir com campos configurados para facilitar a vida do solicitante. Flexibilidade: Um modelo pode ser do tipo "Normal", mas ter um fluxo de aprovação simplificado porque é focado em "Cloud Provisioning".   3. Eles são a mesma coisa? (Respondendo à sua dúvida) Não. Conforme a documentação oficial aponta: Os Change Types estão "dentro" do conceito de modelos: Cada Change Model é associado a um Change Type. O Modelo é o motor que guia a experiência do usuário, enquanto o Tipo é o rótulo que mantém a integridade do processo ITIL. Analogia Prática: Imagine que o Change Type é a categoria da sua CNH (Carro, Moto, Caminhão). O Change Model é o GPS: ele te dá o caminho específico para o seu destino, garantindo que você siga as regras daquela categoria, mas permitindo rotas diferentes dependendo para onde você vai.   4. Por que usar Change Models para apoiar a criação? Redução de Erros: O usuário não precisa saber toda a política de mudanças; ele escolhe o modelo "Troca de Switch" e o sistema guia o resto. Agilidade: Você pode criar modelos específicos para times de DevOps que precisam de menos burocracia, sem mudar a estrutura global de "Normal Change" da empresa. Visualização: A nova Landing Page de Change Management utiliza os Modelos para oferecer uma experiência muito mais intuitiva (estilo "catálogo") do que o antigo menu lateral     ... View more

Guia de Troubleshooting: Metodologia Técnica para Homologação de Ambientes   Resumo: Este guia estabelece o workflow técnico e as melhores práticas para identificação de causa raiz durante processos de homologação, atualizações ou falhas após migrações de ambientes na Now Platform. 1. Introdução: O Princípio da Clareza Antes de iniciar qualquer análise técnica (logs ou scripts), o time de suporte deve garantir que a “pergunta técnica” está correta. O erro mais comum no troubleshooting de homologação é tentar corrigir algo que não foi bem definido. Checklist de Definição (wwww): O que (what): Qual é o comportamento esperado vs. o comportamento atual? Onde (where): Ocorre em todos os registros ou em um específico? (Ex: Apenas no portal ou no backend?) Quem (who): Afeta todos os usuários ou apenas usuários com roles específicas? Quando (when): Começou após um clone, uma atualização de Store App ou uma mudança de configuração manual? Princípios de Definição: A Pergunta Correta: O que o cliente está tentando realizar e o que exatamente está falhando? Frequência e Escopo: O erro é consistente (acontece sempre) ou intermitente? Afeta um usuário específico, uma role ou a instância inteira? O Gatilho: Qual foi a última alteração no ambiente? (Ex: Clone de PROD para DEV, instalação de patch ou alteração de System Property). Estrutura de Reporte de Análise (Padrão S.T.E.P.) Para acelerar a comunicação entre níveis (N1 para N3), toda análise de homologação deve ser reportada seguindo: S (Status): O impacto atual no negócio. T (Trigger): O que dispara o erro. E (Evidence): Logs anexados e códigos de erro específicos. P (Payload): Exemplo de dados (Sys_id) usados no teste. A Correlação entre Metodologias: O QUE? → Corresponde ao S (Status) e T (Trigger) No S.T.E.P.: O Status define o impacto (o que parou) e o Trigger define a ação (o que foi feito para o erro aparecer). Exemplo: “O botão de aprovação sumiu (Status) após o utilizador clicar em ‘Guardar’ (Trigger).” 2. ONDE? → Corresponde ao P (Payload) e T (Trigger) No S.T.E.P.: O Payload indica o Sys_id e a tabela (onde o dado está). O Trigger indica o local funcional (Portal, Workspace ou Backend). Exemplo: “Ocorre na tabela u_request_final (Payload) dentro do Service Portal (Trigger)." 3. QUEM? → Corresponde ao P (Payload) e S (Status) No S.T.E.P.: No Status/Payload incluímos se o impacto é apenas para utilizadores com a role itil ou se é geral. Exemplo: “Apenas utilizadores com a role ‘approver_user’ (Payload) visualizam o erro de ‘Access Denied’ (Status).” 4.QUANDO? → Corresponde ao T (Trigger) e E (Evidence) No S.T.E.P.: A Evidência traz o timestamp dos logs (o momento exato). O Trigger traz o evento que disparou a falha. Exemplo: “O erro foi registado às 14:22 (Evidence) imediatamente após o submetimento do formulário (Trigger).”   2. Workflow de Investigação Técnica Para uma análise eficaz, o suporte deve seguir esta hierarquia de ferramentas: A. Análise de Logs (O “Rastro” do Sistema) Sempre verifique os Log Files antes de tentar reproduzir o erro. System Logs -> Errors/Warnings: Procure por erros de “Scope”, “Access Denied” ou “Null Pointer Exception” que ocorreram no exato momento do teste de homologação.   Transaction Logs: Verifique o tempo de resposta. Se o ambiente de homologação está lento, o Transaction Log dirá se o gargalo é no SQL, no Browser ou no Processamento de Rede.   B. Debugging de Sessão (O Cenário Real)   Utilize as ferramentas de Session Debug para isolar o problema sem afetar outros usuários: Debug Security: Essencial para homologação. Verifica se uma ACL (Access Control) nova está bloqueando a visualização de campos após a migração.   Debug Business Rules: Identifica qual script de servidor alterou um valor inesperadamente durante a homologação.     C. Scripts Server-Side e Client-Side Se o erro for funcional (um botão não funciona ou um cálculo está errado): Server-Side: Use o Script Debugger para percorrer o código linha a linha. Coloque breakpoints em Business Rules ou Script Includes suspeitas. Client-Side: Utilize o JavaScript Log and Field Watcher para entender se o erro está no navegador do usuário (Client Scripts ou UI Policies). D. Deleted Records D. Auditoria de Registros Excluídos (Deleted Records) Nem sempre o problema é o que foi alterado, mas sim o que deixou de existir. Em ambientes de homologação, é comum que registros de configuração sejam excluídos acidentalmente. System Deleted Records: Se um comportamento que funcionava parou subitamente, verifique a tabela de sys_metadata_delete . Ela rastreia componentes de aplicação (como campos, tabelas ou scripts) que foram removidos. Undelete: O Salva-vidas: A ServiceNow permite restaurar registros excluídos através do módulo “Deleted Records”. Se um registro de dados (como um usuário de teste ou um grupo de aprovação) sumiu durante a homologação, você pode recuperá-lo com todos os seus relacionamentos originais. Filtro de Auditoria: Use o histórico de auditoria ( sys_audit ) para identificar quem excluiu e quando, cruzando essa informação com o seu Checklist de Clareza.   E. Node Log File Download (A Caixa-Preta do Servidor) Quando os logs convencionais não apresentam erros, mas o comportamento do ambiente de homologação continua instável, é necessário descer ao nível do servidor. Acesso: System Logs > Utilities > Node Log File Download . Quando usar: Essencial para investigar falhas de integração (Outbound/Inbound), erros de autenticação (SAML/SSO), ou quando um job agendado (Scheduled Job) simplesmente não inicia. Diferencial: Diferente do log do sistema, aqui você tem acesso aos logs brutos do Java e da infraestrutura do nó atual, permitindo identificar erros que a interface do ServiceNow pode não capturar.   F. Evidence (Evidências e Diagnóstico de Infraestrutura) Além dos logs de erro, a evidência definitiva da saúde do ambiente de homologação é extraída diretamente do motor da instância. Logs e Screenshots: Anexe os erros específicos encontrados nos passos anteriores. O “Check-up” Final via stats.do : Como última e crucial evidência, execute o comando stats.do diretamente no navegador (URL da instância + /stats.do). Ele fornece o "DNA" do ambiente naquele exato momento: Versão e Build: Confirme se o patch level é exatamente o mesmo entre os ambientes comparados. Node ID: Identifique em qual nó o erro ocorreu (útil para descartar falhas isoladas de hardware/nó). Servlet Memory: Verifique se há pressão de memória no ambiente de homologação, o que pode causar comportamentos erráticos em scripts que funcionam em Produção. Connected Users: Valide a carga do ambiente no momento do teste. G. XMLStats.do (Análise de Dados Estruturados) Enquanto o stats.do é visual, o XMLStats.do fornece uma visão detalhada e estruturada da performance do nó. O que observar: Ele permite uma análise granular do uso de semáforos, transações de banco de dados e estatísticas do agendador (Scheduler). Uso em Homologação: É a ferramenta ideal para scripts de monitoramento ou para comparar rapidamente dois ambientes em formato de texto estruturado. Ele revela contagens de transações e tempos médios de resposta que ajudam a identificar se o ambiente de homologação está sob estresse incomum.     H. Threads.do (A Visão de Processamento em Tempo Real) O Threads.do é a ferramenta definitiva para identificar processos travados ou "zumbis". O que ele faz: Mostra exatamente o que cada “thread” (linha de processamento) do servidor está executando naquele milésimo de segundo. Diagnóstico de Travamentos: Se a homologação “congelou”, o Threads.do revela qual script ou transação está consumindo todo o processamento do nó. Ele mostra o tempo que cada thread está ativa, permitindo identificar processos de longa duração que estão bloqueando o ambiente.     3. Isolamento da Causa Raiz (A Técnica do “Ponto de Falha”) Durante a homologação de ambientes, use o método de exclusão: Desative e Teste: Desative a última customização feita. O erro persiste? Se sim, a falha é nativa ou de uma configuração anterior. Compare Ambientes: O comportamento em Produção é diferente de Homologação? Use o Compare Environments ou verifique as System Properties ( sys_properties ) – muitas vezes um ID de integração ou uma propriedade de segurança está diferente entre os ambientes. 4. Documentação da Solução (O Ciclo do Conhecimento) O troubleshooting só é considerado encerrado quando o aprendizado é compartilhado/documentado para evitar que o problema se repita no próximo ciclo de homologação. Fato: O que foi encontrado. Causa Raiz: Por que o erro ocorreu (ex: falha de permissão de Cross-Scope). Resolução: Passo a passo da correção aplicada. Documentação Imediata (KCS): Se a solução foi “óbvia” ou “fácil”, ela deve ser um artigo de KB. São as soluções simples que mais consomem tempo do suporte quando não documentadas. Feedback para Automação: Se um erro foi encontrado manualmente, avalie: “Podemos criar um teste no ATF (Automated Test Framework) para que este erro seja pego automaticamente na próxima vez?”   Referências de Apoio Desvendando o Suporte ServiceNow: Benefícios e Recursos Disponíveis A Engrenagem do Suporte de TI: N1, N2, N3, NOC e SOC “A metodologia acima é baseada nas melhores práticas globais de engenharia de suporte. Recentemente, descobri que a própria ServiceNow oferece um treinamento oficial que aprofunda exatamente estes pontos de Debugging e Logs, o que valida que estamos seguindo o caminho padrão ouro da plataforma.”     Créditos da Adaptação Brasileira Este guia foi complementado por: Tiago Macul  Com o apoio da Comunidade NowBridge.     https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://www.linkedin.com/company/now-bridge/       ... View more

Recentemente, em 12 de janeiro de 2026, a ServiceNow publicou os detalhes do CVE-2025-12420. Trata-se de uma vulnerabilidade crítica de escalação de privilégios que afeta especificamente implementações da AI Platform.   Este artigo detalha a falha e, mais importante, fornece os passos técnicos para você validar se sua instância recebeu a devida manutenção.   🔍 O que é o CVE-2025-12420?   A vulnerabilidade foi identificada na estrutura de agentes de IA. Ela permitiria que um usuário não autenticado realizasse operações de personificação (impersonation) dentro do contexto da AI Platform. Severidade: Crítica (CVSS v4.0). Status: Corrigida pela ServiceNow em 30 de outubro de 2025 para clientes hospedados (Hosted). Risco: Até o momento, não há evidências de exploração desta falha na prática.   🛠️ Auditoria Técnica: Como verificar sua instância De acordo com o KB2587317, você pode confirmar manualmente se a correção foi aplicada seguindo estes passos: Acesse a tabela de propriedades ( sys_properties.list ) e verifique se a propriedade sn_aia.aia_a2a_authentication_token existe. Acesse a tabela de verificação de tokens ( token_verification.list ) e localize o registro ‘A2A Default Auth’. Validação: O valor da propriedade no passo 1 deve coincidir exatamente com a string ‘Token’ do registro no passo 2. Atenção: Se a propriedade não existir ou os valores forem diferentes, abra um caso no Now Support com o assunto: “CVE-2025-12420”.   📦 Versões Corrigidas (Store Apps) Se você utiliza instâncias Self-Hosted ou gerencia versões da Store manualmente, certifique-se de estar nestas versões (ou superiores): Now Assist AI Agents (sn_aia): 5.1.18 ou 5.2.19 Virtual Agent API (sn_va_as_service): 3.15.2 ou 4.0.4   Referências e Créditos Descoberta e Relatório: Aaron Costello e AppOmni (via processo de divulgação coordenada). Fonte Original: ServiceNow Knowledge Base (KB2587317) e Comunicação Interna (COMM2414080). Adaptação para a Comunidade: Tiago Macul.       KB2587317 CVE-2025-12420 - AI Security Maintenance - October 2025 - Overview KB CVE-2025-12420: https://nvd.nist.gov/vuln/detail/CVE-2025-55182       https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://www.linkedin.com/company/now-bridge/       #ServiceNow #Security #CyberSecurity #NowAssist #AIPlatform #CVE202512420 #AppOmni #TiagoMacul #nowbridge ... View more

Se você acompanha a evolução do CSDM (Common Service Data Model), sabe que a jornada do "Design" ao "Consume" está em constante refinamento. Com a chegada da Release Yokohama e a prévia do CSDM v.5, estamos presenciando uma mudança de paradigma: o Application Service agora passa a se chamar Service Instance.   Este artigo é uma tradução adaptada do conteúdo original de [David Skowronek / ServiceNow Community], complementada com insights da nossa comunidade brasileira para ajudar você a se preparar para essa transição. 1. Por que a mudança de nome? Historicamente, a classe cmdb_ci_service_auto (Application Service) era focada em representar o "stack" de uma aplicação instalada. Mas o mundo mudou. Hoje, precisamos modelar muito mais do que apenas software: Como representar componentes de rede? Como modelar um serviço de limpeza (Facility) ou um serviço de IA? Como tratar conexões lógicas que não são necessariamente "aplicações"? Ao renomear para Service Instance, a ServiceNow remove a barreira semântica. Agora, podemos modelar qualquer tipo de serviço — seja ele de Rede, Conexão, Dados ou Instalações físicas — mantendo a estrutura de dependências.     2. Novas Classes na CMDB (Store 1.64.0+) Com o update do modelo de classes (novembro de 2024), foram introduzidas subclasses especializadas: Data Service Instance: Para focar em fluxos de dados. Network Service Instance: Para topologias de rede. Connection Service Instance: Para integrações e links. Facility Service Instance: Para serviços prediais e de infraestrutura física. Operational Process Service Instance: Para fluxos de processos de negócio. 3. O Desafio Atual: A Tabela svc_ci_assoc Aqui entra um ponto técnico crucial que adicionamos a este guia: A limitação de visibilidade. Atualmente, processos críticos como Event Management, Incident e Change utilizam a tabela svc_ci_assoc para identificar rapidamente quais serviços são impactados quando um CI (Item de Configuração) falha. O cenário atual: Até o momento, as novas classes de Service Instance ainda não populam automaticamente essa tabela. Apenas as classes legadas (Mapped, Calculated, Tag-Based) o fazem. ⚠️ Recomendação: Se o seu negócio depende fortemente de cálculo de impacto automático no ITOM ou ITSM, não migre seus registros para as novas classes ainda. Continue usando as classes de Application Service mapeadas até que o novo mecanismo de população seja liberado. 4. O Futuro: Desacoplamento da Lógica de População No CSDM 5.0, a ServiceNow planeja desacoplar a "classe" do "método de população". No futuro, você não precisará escolher uma classe baseada em como ela é populada (Tags vs. Relacionamentos). Você escolherá a classe pelo que ela é (ex: um Network Service Instance) e configurará o método de população (Service Map Population Configuration) separadamente. 5. Como se preparar hoje? (Dicas Práticas) Para estar "Future-Ready" (Pronto para o Futuro): Refatoração de Scripts: Se você possui scripts, workflows ou relatórios que apontam especificamente para a tabela cmdb_ci_service_discovered (Mapped Application Service), comece a apontá-los para a classe pai: cmdb_ci_service_auto . Mapeamento de Serviços: Continue mapeando seus serviços, mas foque na integridade dos relacionamentos ( cmdb_rel_ci ). O CSDM 5.0 será muito mais dependente de relacionamentos transversais. Governance: Comece a educar seu time de Governança de Dados sobre o conceito de Digital Product (Produto Digital), que é o nível hierárquico acima do Service Instance no CSDM 5.0. Conclusão A mudança para Service Instance reflete a maturidade da ServiceNow em entender que o TI não é mais uma ilha, mas o motor de serviços que abrangem toda a empresa.     Links de Referência: Artigo Original: Application Service and Service Instance - What is new in Yokohama por @David Skowronek  Documentação Oficial ServiceNow - Service Instance AI ' Introduction Overview of ServiceNow data security capabilities How data security capabilities work together Limitations of Security Data Filters and ACLs Designing the need-to-know principle. Implementation recommendations Practical example of implementation Summary and key take-aways Noel Ambrose. 🚀 Welcome to Part 1 of my CSDM5 deep-dive series!. 🚀 Part 2: Moving from Crawl to Run. 💡 Part 3: AI Control Tower doesn’t fix messy data. 🚀 Part 4 - The Critical Distinction. 🚀 Part 5 - You Don't Need Perfect. 🚀 Part 6 - CSDM Powers All Cross-Enterprise Workflows.   Créditos da Adaptação Brasileira Este guia foi traduzido e complementado por: Tiago Macul  Karin Zan Huke Com o apoio da Comunidade NowBridge.   https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://www.linkedin.com/company/now-bridge/         #ServiceNow #CSDM #YokohamaRelease #ServiceInstance #CMDB #ITOM #ITSM #NowBridge #TiagoMacul #KarinZanHuke ... View more

. Como parte do nosso Guia Definitivo para Blindar sua Instância, inspirado nas melhores práticas de hardening discutidas em nosso livro sobre ServiceNow Security, hoje vamos focar em uma configuração crítica de Instance Hardening: a desativação do JQuery UI Legado.   🔍 O que é o "Legacy JQuery UI Usage"? Muitas instâncias mantêm versões antigas da biblioteca JQuery UI por questões de compatibilidade com customizações feitas há anos. No entanto, essas versões "prepatched" possuem vulnerabilidades conhecidas que podem ser exploradas por atacantes. A propriedade responsável por esse controle é a glide.jquery_ui.legacy .     🚨 O Risco de Segurança Quando essa propriedade está definida como true , a instância carrega versões do JQuery UI que não recebem mais patches de segurança da ServiceNow. Isso abre portas para ataques baseados em vulnerabilidades de bibliotecas desatualizadas.   Na Release Zurich, a recomendação de segurança é clara: esta propriedade deve ser definida como false para garantir que apenas as versões atuais e suportadas sejam integradas.   🛠️ Como ajustar e atingir a conformidade (Compliance) Acesse o Security Center: Vá até as configurações de Instance Hardening. Localize a configuração: "Disable Legacy JQuery UI Usage". Propriedade de Sistema: Procure por glide.jquery_ui.legacy na tabela sys_properties . Altere o valor para: false .   https://<instance>.service-now.com/now/nav/ui/classic/params/target/sys_properties.do%3Fsys_id%3D10cd8445fb351210f106fa126eefdc4d%26sysparm_record_target%3Dsys_properties%26sysparm_record_row%3D1%26sysparm_record_rows%3D1%26sysparm_record_list%3DnameSTARTSWITHglide.jquery_ui.legacy%255EORDERBYDESCsys_updated_on   "If "glide.jquery_ui.legacy" is not set to the recommended value of "false", then older prepatched JQuery UI versions are used which will introduce unpatched vulnerabilities in the library. This could potentially lead to security risks arising from attacks on vulnerabilities discovered in outdated JQuery UI library versions. When false, integrates the current supported JQuery UI version. The system property is a failsafe in case any organizations depend on legacy versions to run their custom implementations. The Glide Property prevents older prepatched JQuery UI versions from being used which introduce unpatched vulnerabilities in the library. The Glide Property is a failsafe in case any organizations depend on the non-patched versions to run their custom implementations."   --PT-BR Se "glide.jquery_ui.legacy" não estiver definido com o valor recomendado "false", versões antigas e pré-corrigidas do jQuery UI serão usadas, o que introduzirá vulnerabilidades não corrigidas na biblioteca. Isso pode levar a riscos de segurança decorrentes de ataques a vulnerabilidades descobertas em versões desatualizadas do jQuery UI. Quando definido como false, integra a versão atual suportada do jQuery UI. Essa propriedade do sistema serve como medida de segurança caso alguma organização dependa de versões antigas para executar suas implementações personalizadas.   A propriedade Glide impede o uso de versões antigas e pré-corrigidas do jQuery UI, que introduzem vulnerabilidades não corrigidas na biblioteca. Essa propriedade serve como medida de segurança caso alguma organização dependa de versões não corrigidas para executar suas implementações personalizadas.     ⚠️ Ponto de Atenção: O Failsafe A ServiceNow mantém essa propriedade como um "failsafe" (mecanismo de segurança) para organizações que possuem implementações customizadas muito específicas que dependem de comportamentos antigos da biblioteca. Antes de alterar em Produção: Teste em Sub-Produção. Verifique Service Portals customizados, UI Pages ou UI Macros que utilizem JQuery UI intensivamente. Certifique-se de que nada "quebrou" visualmente ou funcionalmente.     Estratégias de Identificação: Onde o jQuery está escondido? Antes de aplicar o bloqueio ou a atualização das bibliotecas, é vital mapear o uso atual para evitar a quebra de funcionalidades críticas (o famoso break-fix). No ServiceNow, o jQuery costuma estar "escondido" em customizações de interface. Aqui estão os três métodos principais para identificar o uso antes da blindagem: 1. Varredura de Código (Scripts de Cliente) A forma mais rápida é realizar uma busca textual nas tabelas que carregam lógica para o navegador. Procure pelos termos jQuery( , $. ou $(' nas seguintes tabelas: UI Scripts ( sys_ui_script 😞 Especialmente os marcados como "Global". Service Portal Widgets ( sp_widget 😞 Verifique o campo Client Controller. Client Scripts ( sys_script_client ) e UI Policies ( sys_ui_policy 😞 Em scripts que manipulam o DOM diretamente. Dica Pro: Utilize a ferramenta "Code Search" dentro do ServiceNow Studio para buscar por jQuery em todos os arquivos da aplicação de uma só vez.         2. Auditoria de Dependências no Service Portal Muitos portais utilizam bibliotecas legadas carregadas como dependências de página ou widget. Aceda a Service Portal > Dependencies. Filtre por dependências que referenciam arquivos .js com "jquery" no nome. Verifique quais widgets estão associados a essas dependências para planear a substituição por APIs nativas ou JS puro (Vanilla JS). 3. Diagnóstico em Tempo Real (Browser Console) Para identificar usos que o código estático não revela (como scripts carregados dinamicamente): Abra a página suspeita na instância. Pressione F12 para abrir o Developer Tools e vá ao Console. Execute o comando: console.log(jQuery.fn.jquery); Se retornar uma versão (ex: 1.12.4), o jQuery está ativo e carregado. Use a aba Network para filtrar por arquivos .js e identificar a origem do carregamento da biblioteca. Qual o próximo passo após identificar? Uma vez identificado o uso, a recomendação é seguir a regra do "Shift-Left": Substitua manipulações de DOM por g_form ou g_user . Remova dependências desnecessárias. Teste em ambiente de Sub-Produção com a propriedade de bloqueio ativa antes de mover para Produção.   Conclusão: Evoluindo 1% ao dia Manter sua instância segura não é um evento único, mas um processo contínuo de eliminação de legados técnicos. Ao desativar o JQuery UI antigo, você remove uma camada de risco desnecessária. Este artigo faz parte da nossa série de aprofundamento do SSC (Security Center). Confira os links anteriores no nosso post central! Créditos e Colaboração Este conteúdo foi revisado e enriquecido pelos especialistas da comunidade: Tiago Macul (Liderança e Estratégia SSC) Comunidade NowBridge 🚀 #ServiceNow #Security #CyberSecurity #SSC #InstanceHardening #JQueryUI #ServiceNowBrasil #NowBridge #TiagoMacul     ServiceNow Releases. ServiceNow History. Summary. SSC — O Guia Definitivo para Blindar Sua Instância e Atingir a Conformidade Desabilitar o uso de IU do jQuery legado.       https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://www.linkedin.com/company/now-bridge/       ... View more