Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

開發人員使用 <get> 工作，在 Ant 目標中指定外部 dependency，以擷取由相應的 URL 指定的 dependency。此方法與以下情形在功能上是相同的：開發人員證明每個外部 dependency 為軟體項目中附帶的人工項目，但卻是必要的，因為它可以在執行建置時自動擷取和合併 dependency。

範例 1：以下內容來自 Ant build.xml 組態設定檔案，顯示外部 dependency 的典型參照：

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

使用 Ivy 時，開發人員會指定 dependency 名稱和版本，而不是列出從中擷取 dependency 的明確 URL，Ivy 依靠其基本組態來識別要從中擷取 dependency 的伺服器。使用共同的元件使得開發人員節省了搜尋 dependency 位置的時間。

範例 1：以下來自 Ivy ivy.xml 檔案的摘錄顯示了開發人員如何使用名稱和版本來指定多個外部相依性：

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

使用 Maven 時，開發人員會指定 dependency 名稱和版本，而不是列出從中擷取 dependency 的明確 URL，Maven 依靠其基本組態來識別要從中擷取 dependency 的伺服器。使用共同的元件使得開發人員節省了搜尋 dependency 位置的時間。

範例 1：以下來自 Maven pom.xml 檔案的摘錄顯示了開發人員如何使用名稱和版本來指定多個外部相依性：

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

可配置 CakePHP 以公開除錯資訊，資訊包含錯誤、警告、SQL 陳述式以及堆疊追蹤。生產環境中不應使用 debug information。

範例 1：

    Configure::write('debug', 3);

Configure::write() 方法的第二個參數表示除錯層級。數字越大，記錄的訊息就越詳細。

開啟階段作業時間愈久，攻擊者威脅使用者帳戶的機率就愈大。階段作業仍為作用中時，攻擊者可能會暴力破解使用者密碼、破解使用者的無線加密金鑰，或是從開啟的瀏覽器控制階段作業。如果足夠大量的階段作業正在執行，較長的階段作業逾時時間也會導致無法釋放記憶體，最後造成阻斷服務。

範例 1：以下範例顯示使用 low 階段作業安全性配置的 CakePHP。

    Configure::write('Security.level', 'low');

與 Session.timeout 設定配合使用，Security.level 設定可定義階段作業的有效時間。實際階段作業逾時時間等於 Session.timeout 乘以下列其中一項倍數：

'high' = x 10
'medium' = x 100
'low' = x 300

將純文字憑證儲存在組態或資訊清單檔案中，會讓能夠讀取此檔案的所有人都能夠存取受憑證保護的資源。開發人員有時認為他們無法使應用程式防上那些具有組態設定檔案存取權的人的入侵，但這種作法會造成攻擊者的攻擊更加容易。好的憑證管理原則要求不得以純文字方式儲存憑證。

ClassLoader manipulation 允許攻擊者存取及修改基本應用程式伺服器設定。在 Tomcat 8 等特定應用程式伺服器上，攻擊者可能改變這些設定來上傳 Web shell 及執行任意指令。

DNS Spoofing 又稱 DNS Cache Poisoning，是一種攻擊類型，攻擊者會破壞 DNS 解析器的快取，導致其傳回錯誤的 IP 位址。使用 DNS Spoofing 時，攻擊者可以在使用者不知情的情況下，將使用者重新導向到惡意網站。在使用 Node.js 的伺服器端 JavaScript 環境中，若 DNS 伺服器設定的處理不當，就可能會導致安全弱點。

範例 1：設想這樣一個情境：Node.js 應用程式讓使用者能指定自訂 DNS 伺服器。如果此輸入未經過正確驗證和清理，攻擊者就可以提供惡意 DNS 伺服器並實作 DNS Spoofing 攻擊。

const dns = require('dns');

// User-controlled input for DNS servers
const customDnsServers = from_user_controlled_input;

// Set custom DNS servers
dns.setServers(customDnsServers);

在此範例中，customDnsServers 變數被指派了一個從使用者控制的輸入衍生而來的值。此輸入接著被用於設定使用 dns.setServers(customDnsServers) 的 DNS 伺服器。如果攻擊者提供惡意 DNS 伺服器位址，他們可以引導應用程式使用其伺服器解析網域名稱，進而可能會傳回錯誤的 IP 位址。

當 Dockerfile 沒有指定 USER 時，Docker 容器預設以超級使用者權限執行。這些超級使用者特權會傳播到容器內部執行的程式碼，通常，這些特權高於所需。以超級使用者權限執行 Docker 容器會擴大受攻擊面，可能讓攻擊者能執行更嚴重的攻擊形式。

Dockerfile 可以為相依項和基本映像指定一個沒有界線的版本範圍。如果攻擊者能將惡意版本的相依項新增至儲存庫，或欺騙組建系統從攻擊者控制的儲存庫下載相依項，那麼如果 docker 設定為沒有特定版本的相依項時，則 docker 將以無訊息方式下載並執行遭入侵的相依項。

這種類型的弱點可能因為供應鏈攻擊而被利用，在供應鏈攻擊中，攻擊者可運用開發人員的錯誤組態，接著誤植域名，然後可將惡意套件新增至開放原始碼儲存庫。這種類型的攻擊利用對已發佈套件的信任來獲取存取權限並竊取資料。

在 docker 中，latest 標籤會自動指示未使用摘要或唯一標籤為其提供版本的映像的版本層級。Docker 會自動指派 latest 標籤做為指向最新映像資訊清單檔案的機制。由於標籤是可變的，所以攻擊者可使用 latest (或弱標籤，如imagename-lst, imagename-last, myimage) 取代映像或階層。

範例 1：以下組態指示 Docker 挑選使用最新 ubuntu 版本的基本映像。

    FROM ubuntu:Latest
    ...

Docker 不會驗證設定為支援套件管理器的儲存庫是否值得信賴。

範例 2：以下組態指示套件管理器 zypper 擷取指定套件的最新版本。

...
zypper install package
...

在 Example 2 中，如果儲存庫遭到入侵，攻擊者可能很容易便上傳符合動態標準的版本，使 zypper 下載相依項的惡意版本。

Dockerfile 中包含的 USER 指令設為 root 時，會擁有能在容器內進行變更的過高特權。這違反了以最低特權執行映像的原則。通常，安裝套件和建立資料夾可能需要 root 權限。安裝完成後，最好的做法是新增具有限制特權的使用者。

依據預設，Docker 會允許將具有特權的連接埠繫結至容器，並且如果使用者未宣告連接埠，則 Docker 會將容器連接埠對應至 49153-65535 範圍內的可用連接埠。在許多情況下，需要開啟某些連接埠才能執行服務，並且隨著時間的流逝，開啟的連接埠數量可能會越來越多。開啟的連接埠會增加攻擊面，對於以更高特權執行的服務更是如此。請確保僅開啟該特定服務所需的連接埠。當服務不需要更高的特權時，請在具有特權的連接埠範圍之外的連接埠上執行服務。

您可以使用 docker inspect 和 history 指令從公開的 Docker 映像檔重建構 Dockerfile，或者透過第三方工具自動執行此程序。如果使用 ADD/COPY 指令新增了敏感資訊，則攻擊者可以重新建立每個 docker 層以取得該資訊。

使用 Volumes 也可能公開敏感目錄。如果需要使用 Volumes 來保存資料，請避免掛接敏感目錄。

當 Secure Shell (SSH) 服務在容器中執行時，將很難管理存取原則、金鑰、密碼和安全性升級。

使用 CDN 來執行依賴應用程式的 JavaScript，透過從應用程式擁有的伺服器執行 JavaScript 可提供許多優點。對應用程式所有者來說，這些優勢包括增加效能並減少需要維護的程式碼。但是，應用程式假設 CDN 會傳遞安全的內容至瀏覽器中。如果攻擊者危及 CDN，則 CDN 將傳遞惡意程式碼至使用者的伺服器。應用程式無法控制使用者瀏覽器現在執行的程式碼，或者透過偵測將其視為惡意程式碼。

範例 1：藉由參照 Microsoft CDN，下列 ASPX 程式碼包含 Microsoft 的 jQuery 程式碼：

...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...

範例 2：下列 ASPX 程式碼可讓 ASP.NET 框架 Script 的要求自動重新導向至 Microsoft Ajax CDN：

...
<asp:ScriptManager
   ID="ScriptManager1"
   EnableCdn="true"
   Runat="Server" />
...

Example 2 中，ScriptManager 控制可配置其 ASPX 頁面，以便自動重新導向所有指令碼要求至適當的 CDN。

如果使用 Blaze DS 來記錄所有無法預期的事件，services-config.xml 描述符號檔案會指定「記錄」XML 元素以描述記錄的不同內容。內容將與下列相似：

範例 1：

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

此 target 標籤有一個名為 level 的選擇性屬性，由它來指示記錄層級。如果除錯層級設定的層級過於詳細，應用程式可能會將敏感資料寫入記錄檔案。

未針對靜態資料啟用客戶自管加密金鑰 (CMEK)。

依預設，Google Cloud 使用隨機產生的資料加密金鑰 (DEK) 來加密靜態資料。CMEK 功能允許組織使用自己選擇的加密金鑰來加密 DEK。這讓組織可以妥善控制和記錄加密過程。

因此，CMEK 通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰
- 防篡改硬體安全性模組

若將存取權或 BigQuery 角色授予特殊主體類型 (例如 allUsers 和 allAuthenticatedUsers)，任何人都可以存取敏感資料。

未針對靜態資料啟用客戶自管加密金鑰 (CMEK)。

依預設，Google Cloud 使用隨機產生的資料加密金鑰 (DEK) 來加密靜態資料。CMEK 功能允許組織使用自己選擇的加密金鑰來加密 DEK。這讓組織可以妥善控制和記錄加密過程。

因此，CMEK 通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰
- 防篡改硬體安全性模組

未針對靜態資料啟用客戶自管加密金鑰 (CMEK)。

依預設，Google Cloud 使用隨機產生的資料加密金鑰 (DEK) 來加密靜態資料。CMEK 功能允許組織使用自己選擇的加密金鑰來加密 DEK。這讓組織可以妥善控制和記錄加密過程。

因此，CMEK 通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰
- 防篡改硬體安全性模組