Rust 的基礎 - Copy, Clone

在 所有權規則 那篇中，談到了

 

let hello = "Hello World".to_string()

let hello2 = hello;

 

在 Ownership 規則之下， hello 所持有的 Value 被移轉給 hello2，因此 hello 之後無法被使用。

這種規則可以止諸如 Dangling pointer, Use After Free 等。但想阻止這些情況除了 Move，其實也可以選擇複製。

let hello2 = hello.clone();

使用 clone 的話，hello 與 hello2 就各自持有單獨的一份 "Hello World"

此外對於一些基礎型別(如整數，浮點數)來說，它們在使用 = 時，行為就不是 Move 而是 Clone

let value = 123;

let value2 = value;

println!("{} {}", value, value2);

// value, value2 都有效

在 Rust 中，支援 Clone 的型別就有 clone 可用，支援 Copy 的型別遇到 = 時就是使用 clone。

Rust 的基礎- 所有權規則

 Rust 中

1. 每個 Value 都有 "所有者"
2. 在任意時刻只會有一個 "所有者"
3. 當所有者離開其所在範圍時，Value 會被 Drop

第一條規則

let hello = "Hello World".to_string()

此範例 "Hello World" 是 Value, 所有者是 hello

 

第二條規則

let hello2 = hello;

此範例中 hello 所擁有的 "Hello World" 被轉移(Move) 給 hello2.

此時若在使用 hello, 則會編譯錯誤

16 |    let hell2 = hello;
   |                ----- value moved here
17 |    println!("{}", hello);
   |                   ^^^^^ value borrowed here after move

第三條規則

let hello = "Hello World".to_string()
{
    let hello2 = hello;
    // <-- 在離開 Scope 後, "Hello World" String 就被 Drop 了
}


從以上的三條規則來看，這些規則可能可以防範

1. Dangling Pointer (由於一次只有一個 Owner, 被 Move 就失效因此無法再存取)
2. Use After Free (由於一次只有一個 Owner, 被 Move 就失效因此無法再存取)
3. Memory Leak (Circular 會有狀況)

Dependency Track - SBOM 產生

使用 Dependency Track 時，最麻煩的莫過於產生軟體清單。好在存在一些可從套件管理系統產生清單的軟體。

Python(PIP)

pip install cyclonedx-bom

cyclonedx-py -r -i requirements.txt.lock  --format json -o cyclonedx.json

 

requirements.txt.lock 的部份內容是

 

awscli==1.29.62
azure-core==1.29.4
azure-storage-blob==12.18.2
botocore==1.31.62

將最終產生的檔案後上傳

NPM

npm install @cyclonedx/cyclonedx-npm

./node_modules/.bin/cyclonedx-npm ../Angular/package-lock.json  --output-file cyclonedx.json

package.json 內容只有

"@angular/cli": "^16.2.5"

將最終產生的檔案後上傳

 

Dependency Track

 目前一家軟體公司在開發應用系統時，一般都會使用到第三方軟體，可能是 Library 或者是 Application 等等。而隨著時間經過，這些用到的第三方軟體可能會有弱點被逐步發現，進而影響既有系統安全性。

在 OWASP 2021 top ten 之中，"A06:2021 – Vulnerable and Outdated Components" 就高居第六項安全風險。在其中也給出了如何避免風險的建議

1. 移除不必要的依賴，功能，元件與檔案 
2. 持續使用工具清點 Client 端與 Server 端使用到的元件與其依賴的元件
3. 持續使用使用自動化工具，以 CVE 與 NVD 來監控元件的弱點，以 Email 來收取安全通知警告
4. 只從官方來源獲取資源，並只使用簽署過的 Packages
5. 持續監控沒有維護或沒有為舊版本創建安全修正的 Library 或元件

在檢查是否使用到了有問題的 Library 或元件，很多語言的套件管理工具都有提供掃描功能：比如 npm, Composer, Cargo 等等，但對 C/C++ 雖然有 conan 這個套件管理系統，但由於非標準，組織未必有使用或者需要的 Package 並未收錄其中。 

在找尋追蹤方案的過程中，我發現了 depedency track 這個解決方案，其是這樣介紹自己的

Continuous SBOM Analysis Platform

SBOM 是 "Software Bill of Materials" 的縮寫，代表開發時使用到的元件。

想使用這各平台，可以簡單的透過 Docker Composer 來使用

curl -LO https://dependencytrack.org/docker-compose.yml
docker-compose up -d

啟動後的可以透過 http://127.0.0.1:8080 來存取，預設的帳號密碼是 admin/admin

以下是我創建的一個範例用的專案

 

 

 

 

點開 curl 在 vulnerabilities 中可以看到該版本的弱點

 

 

 

 

為了要讓其可以抓到對應的版本，我目前是在 CPE 中填入

 

 

 

 

 

 

 

 

 

 

目前實測軟體版本比對有時可能會有問題，有可能會比到上古版本的安全問題

 

安全資料主要來自 NVD，會自動更新

 

當然也有通知功能

 

 

 

 

 

其也有提供 OpenAPI 界面來幫助與現有的開發流程進行整合

 

 

 

 

 

 

日後有其他使用上的心得會更新上來。