每個組織都知道自己有影子IT。一個數據具體說明了問題的嚴重性：大多數組織運行超過1,000個雲端應用程序，而IT部門通常只能監控到其中不到10%的應用程式。大型企業平均擁有473個SaaS應用程式；IT部門直接管理的卻寥寥無幾。 80%的員工使用未經授權的應用程式來完成工作。這些數據在所有研究中都保持一致，因為它們反映的動態是一致的：員工和業務部門傾向於採用能夠快速解決燃眉之急的工具，而IT治理流程卻無法及時評估和批准這些工具。
2026 年關於影子 IT 的討論主要集中在 SaaS 發現工具上，這些工具透過掃描 DNS 日誌、分析 SSO OAuth 令牌、審核費用報告和識別網路流量來尋找員工未經授權使用的雲端應用程式。這些工具解決了 SaaS 層面的問題，而且效果相當不錯。但它們無法解決，也沒有任何 SaaS 發現工具能夠解決的，是影子 IT 的另一個層面：企業應用程式組合中存在的客製化應用程式、未記錄的批次程式、非正式資料管道和幽靈實用程序，這些程式從未出現在任何資產管理系統、變更日誌或 IT 清單中。這些並非員工部署的雲端應用程序，而是運行在大型主機和中型機系統上的生產程序，執行著企業無法完全掌控的關鍵業務功能。
這兩個問題需要不同的發現方法。 SaaS 影子 IT 問題需要網路可見性和身分整合。程式碼級影子 IT 問題則需要解析實際的軟體工件，包括原始碼、載入庫和 JCL 作業流，以列舉存在的程式及其功能。本指南涵蓋這兩個方面，並特別關注該領域其他研究尚未涉及的第二類問題。
影子IT的兩大難題
影子IT通常被定義為組織內部未經IT部門明確批准或知曉而使用的技術。這個定義涵蓋了兩種截然不同的現象，需要不同的發現方法和不同的治理措施。
影子SaaS和雲端工具是指員工或業務部門未經正式IT採購流程而採用的應用程式和服務。例如，行銷團隊使用未經批准的AI寫作工具；財務團隊透過個人Dropbox帳戶共享電子表格；開發人員使用未經授權的AI編碼助手，並將專有原始碼傳送到外部API。這些應用程式存在於組織基礎設施之外，可透過外部訊號發現，例如DNS查詢、OAuth授權、費用報銷明細和網路流量指紋。
本文重點關注的「影子應用軟體」是指在組織自身基礎設施內創建但從未被妥善記錄、清點或管理的定製程式和批次流程。例如，1994年財務部門的一名開發人員編寫了一個COBOL程序，用於處理特定的稅務計算特殊情況；業務分析師編寫了一個RPG程序，用於為特定貿易夥伴生成EDI文件；一個JCL作業，每月月底運行，產生合規團隊依賴的監管報告，該作業由一名2009年離職的承包商編寫；以及一個Java實用程序，該程序在2018年系統集成項目中“臨時”編寫，卻在未經任何人批准的情況下變成了永久依賴項。
這些程式在 DNS 日誌中不可見，因為它們運行在內部基礎架構上。它們也不會出現在 OAuth 授權記錄中，因為它們早於 OAuth 出現。它們不在官方應用程式清單中，因為它們從未正式提交給 IT 管理部門審核。只有透過檢查基礎架構本身、載入庫、原始碼庫、作業排程器和執行日誌，才能發現它們，因為這些日誌會揭示環境中實際運行的軟體。
這件事的重要性不僅在於確保資產清單的完整性：74% 的組織都曾因未知或未管理的資產而遭遇安全事件。影子應用軟體就屬於這類未知資產，無論是基於網路的發現工具還是 SaaS 視覺化平台都無法找到它們。
為什麼影子應用軟體會不斷累積
了解為什麼未記錄的自訂應用程式在企業環境中氾濫，就能解釋為什麼標準治理流程無法阻止這種情況，以及為什麼需要進行回顧性發現。
立即解決問題勢在必行。業務部門面臨特定的營運問題，需要特定的解決方案。已獲批准的應用程式無法處理特殊情況。 IT 請求佇列積壓嚴重。開發人員（有時是 IT 部門的，有時是業務團隊的）編寫了一個可行的解決方案。該解決方案運作正常，解決了問題，並成為營運工作流程的一部分。由於問題已經解決，正式的治理流程從未啟動。
臨時方案變成永久方案的模式。最陰險的影子應用軟體往往始於一個明確的臨時解決方案。 「只是暫時的，直到真正的系統準備就緒。」「資料格式問題的快速變通方案。」「在我們等待供應商修復其 API 期間的臨時方案。」當圍繞這些臨時方案累積的依賴項從未被移除時，它們就會變成永久方案。例如，為解決千年蟲問題而編寫的 COBOL 日期計算修復程序，在 2 年後仍然被調用，因為後續開發人員不知道它存在的意義，也不知道移除它是否安全。又如，由於目標應用程式從未真正構建，一個「臨時」的資料庫規範化腳本最終變成了夜間批次的一部分。
知識移轉失敗。由特定人員建立的影子應用程序，隨著這些人的離職，也離開了組織的文檔化知識庫。程式繼續運行，嵌入到依賴它的生產流程中，但卻沒有任何文檔，沒有所有權歸屬，也沒有人足夠了解它的具體功能，從而無法安全地對其進行修改。它就像生產環境中的幽靈：其影響顯而易見，但其管理卻無從知曉。
影子資料管道。資料整合尤其容易滋生未經規範的自訂軟體。當官方 ETL 層不支援所需的資料轉換，或是業務流程需要資料在系統間快速移動，而官方整合流程又無法滿足此要求時，開發人員就會建立非官方的資料移動程序。例如，一段 Python 腳本查詢生產資料庫，並將結果寫入共用驅動器，供下游流程讀取；又如，一段 COBOL 程式從大型機 DB2 資料庫讀取數據，並寫入平面文件，供雲端應用程式使用。這些非官方的數據管道跨越系統邊界，處理潛在的敏感數據，並且完全遊離於整合治理框架之外。
影子應用軟體的四類
第一類：業務部門自訂應用程式
由嵌入業務部門、財務、採購、營運、合規等部門的開發人員建立的程序，旨在解決特定領域的問題。這些程序通常：
- 名稱非正式（TAXCALC、VENDREPT、ADJBATCH），未遵循企業命名規範
- 儲存在由業務部門而非 IT 部門管理的目錄或庫中。
- 配置管理資料庫（CMDB）中沒有條目
- IT服務管理系統中沒有指定的技術負責人
- 缺乏正式文件、測試覆蓋率和變更控制歷史記錄
由於業務部門了解程式的功能並將其視為“自己的”，因此這些程序的重要性常常被低估。而IT部門並不知道這些程序的存在，所以無法評估其重要性。由於IT部門的應用程式清單中缺少這些程序，因此它們也不在業務連續性計劃 (BCP)、災難復原計劃、安全評估和現代化改造計劃的考慮範圍之內。
第二類：幽靈程序
這些程序出現在生產環境中，但其來源、用途和所有權對當前組織而言卻無從得知。它們存在於載入庫和原始碼庫中，會被其他程式調用或由 JCL 作業調用，它們產生的輸出是下游進程所依賴的，但組織已經遺忘了它們存在的原因以及責任人。
從安全和合規的角度來看，幽靈程序尤其危險，因為它們無法根據當前標準進行審查，無法納入需要分配應用程式所有權的漏洞掃描程序，也無法進行監管合規性評估，因為沒有人知道它們存取哪些資料或它們服務哪些業務功能。
第三類：影子資料管道
非官方程式會在官方認可的整合架構之外，在系統之間傳輸資料。這些程式種類繁多，從複雜的 ETL 替代方案到簡單的檔案傳輸腳本，應有盡有：
蟒蛇
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")該程式代表了企業環境中常見的一種模式：它使用硬編碼的生產資料庫憑證，將敏感的計費資料寫入未加密的共享網路位置，並且在作者離開公司後多年仍未受到監控。由於它運行在內部基礎設施上，因此不會出現在任何 SaaS 發現工具中。由於它使用不會產生任何可區分特徵的標準資料庫協議，因此也不會出現在網路流量分析中。它只能在原始碼中被發現。
第 4 類：未記錄的批次作業
JCL 作業流程和計畫程序在生產基礎架構上運行，但未包含在官方作業計畫文件中。這些作業流程和計畫程序透過以下方式累積：
- 透過直接提交的方式，在標準作業排程程序之外提交作業
- 從其他程式內部動態呼叫的程式（因此在調度程序清單中不單獨可見）
- 運行頻率較低的作業，例如在月末、年末或僅在特定業務情況下運行的作業，且從未被納入例行庫存審計。
- 從先前系統繼承的、已「遷移」但從未正式停用的作業
未記錄的批次作業在下列情況下會成為關鍵故障點：
- 維護窗口會影響他們運作的系統，但沒有人知道要通知依賴他們輸出的業務部門。
- 已執行安全性評估，這些作業以具有提升權限的未監控服務帳戶執行。
- 現代化改造專案根據已記錄的作業計畫來規劃遷移範圍，但遷移到目標環境後卻發現缺少關鍵的批次功能。
以影子軟體類別劃分的發現方法
適用於 SaaS 影子 IT 的發現方法大多不適用於影子應用軟體。所需的方法如下：
載入庫分析。所有曾經編譯並部署到大型主機或中型機系統的程式都存在於載入庫（即可執行檔案庫）中。將載入庫中的程式與官方應用程式清單中的程式進行比較，可以發現差異：庫中出現但清單中未包含的每個載入模組都是一個影子程式。此分析無需原始程式碼，它直接操作已編譯的可執行檔及其元資料。
原始碼庫遍歷。原始碼庫（COBOL 原始碼 PDS、Git 倉庫、RPG 原始碼庫）包含所有已編寫的程序，包括非正式編寫、非正式部署且從未在 IT 管理系統中註冊的程序。透過遍歷整個原始程式碼庫並與組態管理資料庫 (CMDB) 進行比對，可以發現原始碼中存在但沒有管理記錄的程式。
JCL 和調度器核對。每個在生產環境中執行的 JCL 作業流程，無論是透過官方調度器提交、手動提交或由其他作業調用，都會在作業執行日誌（JESLOG、SYSLOG）中留下痕跡。將生產執行日誌中出現的程序與官方清單中的程序進行比較，可以識別出那些在生產環境中運行但未納入監管範圍的程序。
動態調用分析。當程式動態呼叫其他程式時（被呼叫程式的名稱在執行時期而非編譯時決定），會產生靜態調度器分析無法辨識的依賴關係。動態呼叫分析可以追蹤哪些程式發出具有可變程式名稱的 CALL 語句，識別可能被呼叫的程式範圍，並標記可透過動態調度到達但可能未出現在任何靜態依賴關係圖中的程式。
資料流追蹤。透過分析檔案系統和資料庫存取模式，可以發現影子資料管道：哪些程式從哪些資料集、檔案或資料庫表中讀取或寫入資料。如果一個程式從生產資料庫讀取資料並寫入標準資料管理層級以外的檔案路徑，則該程式很可能就是影子資料管道的候選對象。
暗影人工智慧維度
到2026年，影子IT問題將進一步演變為影子人工智慧，即員工和業務部門未經IT部門授權使用人工智慧工具和代理。根據IBM發布的《2026年資料外洩成本報告》，43%的安全事件與員工使用影子人工智慧有關。 Gartner預測，到2030年，超過40%的企業將遭遇與未經授權的影子人工智慧相關的安全或合規性事件。
影子人工智慧帶來的具體風險與程式碼級影子IT直接相關：專有原始碼被導入人工智慧編碼助理。例如，一名員工未經授權使用人工智慧編碼助理來協助處理遺留的COBOL程序，就等於將該程式的原始程式碼發送給了外部人工智慧提供者。這些原始程式碼可能包含硬編碼的憑證、構成商業機密的業務邏輯，或違反資料駐留要求的資料結構。針對這種特定風險的發現方法並非網路流量分析，而是檢測哪些程式已被與外部人工智慧API通訊的工具訪問，這需要應用層監控而非網路層監控。
影子人工智慧問題和影子應用軟體問題有一個共同的重要特徵：它們都無法被目前主導SaaS影子IT市場的基於網路的發現工具所察覺。兩者都需要透過應用層監控或結構化程式碼分析才能被發現。
建立完整的應用程式清單
企業應用軟體影子 IT 發現程式的輸出結果是一份涵蓋四類人群的核對清單：
已知且已記錄：指同時存在於官方清單和實際生產環境中的程序。這些程序具有管理權限、指定負責人、變更控制歷史記錄和災難復原計劃。
已知但未部署：指出現在官方清單中，但在載入庫或生產執行日誌中找不到的程式。這些程序可能已準備退役，也可能已停用但未進行正式的退役程序，或可能被錯誤地列入清單。
未知但已部署（影子程式）：出現在生產執行日誌或載入庫中，但未在官方清單中登記的程式。這些是影子 IT 的核心發現，需要立即進行所有權分配、安全評估和治理註冊。
未記錄的依賴項：這些程式既未出現在官方清單中，也未出現在主要生產執行日誌中，但透過動態呼叫分析或資料流追蹤發現，它們可以從生產進程存取。這些程序被稱為“幽靈程序”，它們最難發現，如果不加以發現，後果最嚴重。
這四個群體之間的和解產生了行動計劃：登記影子計劃，評估其安全狀況，分配所有權，確定其處置方式，進行管理和維護、現代化改造或退役。
SMART TS XL 執行程式碼級影子IT發現
SMART TS XL的影子 IT 發現方法能夠解決基於網路的工具無法觸及的程式碼級類別。
靜態程式碼分析功能始於對原始程式碼庫的全面遍歷：環境中所有 COBOL 程式、RPG 模組、PL/I 應用程式、Java 服務、Python 腳本和 JCL 作業流程都會被編入目錄，包括其原始程式碼位置、語言、大小和初步複雜度概況。該清單是 CMDB 和官方應用程式註冊表進行比對的基準。出現在原始碼庫中但未出現在官方清單中的程序，即為主要的影子應用程式。
應用程式依賴關係映射解決了動態 CALL 問題：透過追蹤每個程式中的每個 CALL 語句（包括程式名稱是變數的動態呼叫），依賴關係映射可以辨識出即使從未出現在靜態排程器清單中，也能從生產程序存取的程式。例如，一個被十個生產程序動態呼叫的「幽靈程式」即使沒有獨立的 JCL 作業定義，也會出現在依賴關係映射中。
JCL擴充功能可以追蹤每個 JCL 作業流程的完整執行鏈：解析 PROC 參考、展開符號參數，並建立每個作業呼叫的完整程式對應。將此對應與官方作業排程文件進行比較，即可自動識別出生產環境中執行但文件未涵蓋的作業和程序。
影響分析功能使發現的結果能夠付諸行動：對於每個發現的影子程序，列出所有依賴它的生產流程。沒有相依性的影子程式屬於死程式碼候選對象，可以安全地棄用。有二十個生產依賴項的影子程序是一個關鍵的未記錄資產，需要立即進行管理關注。影響範圍決定了修復的優先順序。
企業級搜尋功能使整個清單可查詢：尋找存取特定資料集的每個程式（潛在的影子資料管道候選程式）、在特定日期之後編寫且沒有 CMDB 條目的每個程式（近期影子應用程式）、以及寫入標準資料管理層級之外的外部文件路徑的每個程式。此搜尋功能既支援初始發現工作，也支援持續監控，以防止在初始清理後影子應用程式再次累積。
對於開展遺留系統現代化改造專案的組織而言，發現影子應用程式是必不可少的先決條件。如果一個現代化改造專案僅基於官方應用程式清單來規劃遷移範圍，卻在執行過程中才發現影子應用程序，那麼該專案在最初制定時，其範圍、時間表和預算就都存在問題。原本應該在規劃前完成的發現工作，現在卻在執行過程中進行，而此時成本最高。
治理因應措施：不阻撓，而是提高透明度
那些在2026年能夠有效管理影子IT的組織已經意識到，一刀切的禁令不僅行不通，反而會造成不良誘因。大多數組織之所以無法有效回報影子IT，原因只有一個：員工預期會受到懲罰。當財務團隊成員使用未經批准的費用追蹤工具並自行報告時，安全團隊的訓誡實際上已經讓該員工以及所有與他交談過的人下次都保持沉默。
同樣的原則也適用於影子應用程式軟體。如果開發人員建立了一個對業務至關重要的 COBOL 實用程序，而該程序是組織所依賴的，那麼不應因為開發人員當時沒有遵循可能溝通不良的治理流程而受到懲罰。針對影子應用程式的發現，治理措施應包括：
註冊而非移除。如果發現影子程序位於業務流程的關鍵路徑上，它們並非需要移除的影子程序，而是需要進行治理的未記錄生產應用程式。應註冊這些程序，指定負責人，評估其安全狀況，並像對待其他任何生產應用程式一樣，對其採取相同的治理措施。
鼓勵自我揭露。一項治理計劃為業務部門創建安全管道，使其能夠披露已開發的非正式應用程序，從而比任何技術發現方法都能更快地揭露影子軟體。該計劃確保披露後將獲得治理支援、文件編寫協助、安全審查和正式註冊，而不是受到紀律處分，從而消除了隱瞞的動機。
透過流程預防。影子應用堆積的根本原因在於治理摩擦：申請開發新應用的官方流程比業務問題所需的速度慢。減少這種摩擦，例如採用輕量級快速開發治理、在業務部門嵌入IT治理支援、簡化低風險內部工具的審批流程，無需持續的技術探索，即可降低新影子應用的創建速度。
你以為你擁有的庫存，並非你實際擁有的庫存。
IT部門維護的應用清單與企業環境中實際運作的應用軟體之間存在著巨大的差異。在擁有數十年應用軟體累積的大型組織中，已記錄的應用軟體與實際運行的應用軟體之間的差距可能接近總數的30%。這30%未被記錄的應用軟體包括處理敏感資料、執行合規功能、處於業務流程關鍵路徑上的應用軟體，以及存在安全漏洞但無人審查的軟體，因為沒有人意識到這些漏洞的存在。
SaaS影子IT發現工具能夠很好地解決雲層面的影子IT問題。然而，程式碼層面的影子IT問題，例如充斥企業遺留環境中的自訂程式、幽靈工具、非正式資料管道和未記錄的批次作業，則需要採用不同的方法：對實際軟體工件進行結構分析，而不是監控網路流量。這種分析得出的清單往往令人驚訝地完整。從事這項工作的組織經常發現，他們以為在生產環境中運行的程序與實際運行的程序之間存在顯著差異。彌合這一差距是所有治理、安全、業務連續性計劃 (BCP) 和現代化計劃的基礎，這些計劃都依賴於了解組織的實際運作情況。
