使用 PasswordText 類型的密碼時，可能表示實際的密碼以純文字傳送。WS-Security UsernameToken 設定檔說明 UsernameToken <Password> 標籤所傳送的文字，不受限於實際密碼。可以改用密碼衍生物。不過，開發人員通常會傳送實際密碼而不是密碼延伸。傳送未加密密碼或甚至雜湊密碼都可能將憑證暴露給網路資料攔截者。

使用 UsernameToken 的服務供應商可能會接受以純文字傳送的密碼。在未加密的通道上傳送純文字密碼，可能會使攻擊者攔截 SOAP 訊息以取得憑證。

範例 1：以下 Axis 服務供應商配置使用 UsernameToken：

<deployment xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

使用 PasswordText 類型的密碼時，可能表示實際的密碼以純文字傳送。WS-Security UsernameToken 設定檔說明 UsernameToken <Password> 標籤所傳送的文字，不受限於實際密碼。可以改用密碼衍生物。不過，開發人員通常會傳送實際密碼而不是密碼延伸。傳送未加密密碼或甚至雜湊密碼都可能將憑證暴露給網路資料攔截者。

在未加密的通道上傳送純文字密碼或雜湊密碼，可能會使攻擊者攔截 SOAP 訊息以取得憑證。

範例 1：以下 Axis 用戶端配置使用 UsernameToken：

<deployment xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

Bean 屬性名稱和值在填入任何 bean 之前皆需驗證。Bean 填寫功能允許開發人員設定 bean 屬性或巢狀屬性。攻擊者可利用此功能存取類似於 class.classLoader 的特別 bean 屬性，這些屬性允許攻擊者取代系統屬性，並可能執行任意程式碼。

範例：以下程式碼會設定使用者控制的 bean 屬性，但不正常驗證屬性名稱或值：

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

利用 Apache Ivy 自動化 dependency 管理系統，使用者可為 dependency 指定版本狀態 (也稱為動態版本)，而非列出特定版本。如果攻擊者能夠危害 dependency 儲存庫，或欺騙 build system 從攻擊者控制的儲存庫下載 dependency，那麼 build system 只需下載動態修正說明符號，而該說明符號可能執行受危害的 dependency。除了安全性風險之外，動態修正還會為 Code Quality 帶來下列風險：動態修正使軟體的安全性和穩定性受控於第三方，即開發和發行軟體所使用的 dependency 的第三方。

在建置過程中，Ivy 會連接到儲存庫並企圖擷取與所列出狀態相符的 dependency。

Ivy 接受以下的動態修正說明符號：

- latest.integration：選擇 dependency 模組的最新修正。
- latest.[any status]：選擇至少處於指定狀態的 dependency 模組的最新修正。例如，latest.milestone 會選擇重要的修正版本，或是發行版本，而 latest.release 僅會選擇最新發行版本。
- 任何結尾為 + 的修正：選擇 dependency 模組的最新子修正。例如，如果 dependency 存在於 1.0.3、1.0.7 及 1.1.2 修正版本中，則指定為 1.0.+ 的修正版本會選擇 1.0.7 修正版本。
- 版本範圍：表示範圍的數學符號 (例如 ) 可用來對應版本的範圍。

範例 1：以下的組態項目會指示 Ivy 擷取 clover 元件的最新發行版本：

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

如果儲存庫受到危害，攻擊者可很容易便上傳符合動態標準的版本，使 Ivy 下載 dependency 的惡意版本。

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。

範例：以下內容來自 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 時造成一次危害，便會危害執行建置的機器。