鳩小屋

落書き帳

ウクライナ戦況 リマン掃討戦

前回のイジューム奪還からウクライナ軍が東進をつづけているようです。

リマン方面

ウクライナ戦況 Spearhead Operation - 鳩小屋

今回紹介するのはLyman(リマン)包囲戦になります。
リマンはイジューム東方にある町で9月末からウクライナ軍に半包囲されていました。

ロシア軍はこの町に固執して防衛をつづけたものの、ついに耐えきれなくなり撤退を開始したようです。
ただし、すでに退路はウクライナ部隊の射程にあり一方的な掃討戦となったようです。

ロシア軍はリマン部隊の撤退を援護するためにザリチネ(赤強調マーク)へ部隊を増派したようですが、この部隊も想像を超えたポンコツだったようです。
この増援部隊はウクライナ軍に南北から挟撃されることに気付くと、すぐ隣にあるトルスクに撤退しました。
百歩譲ってそこまではよかったのですが、あろうことか追撃から逃れるために橋を爆破してしまいました。
はい。西に撤退できていない部隊がいるにもかかわらずです。

撤退車列には待ち伏せ砲撃が加えられ、徒歩で逃走する兵士は地雷や機銃で倒れていったようです。
近くの森に逃れる兵士もいたようですが、こちらもウクライナ軍が構えていたため、一方的な殲滅だったようです。
リマンの北にあるスタフキー(赤枠)では、スペツナズや精鋭を集めた部隊も十分な陣地がない状態で砲撃にさらされ、最後は機械化部隊により壊滅したようです。
リマンには正規軍も含めて数千人の部隊がいたようですが、死傷または捕虜で半数以上が戦闘不能になったと思われます。

最後に、本来であれば河川を境界とした防衛線(緑線)、国道を境界とした防衛線(青線)にラインで立て直すのが無難ですが、前述のポンコツ部隊や正規部隊の壊滅で前者はすでに突破、後者の突破も時間の問題という状況です。特に国道を境界とした防衛線の北部にあるスバトボは補給の要所であるため、ここが落ちれば補給先のロシア軍は壊走することになりそうです。

ヘルソン方面

ヘルソン方面も大きく動いているようですね。
ウクライナ側が北西から防衛線を突破して川沿いに反攻しているようです。
ロシア側は270度包囲されたような状態ですので、場合によってはリマンと同じようなことになるかもしれません。

こちらは戦況が動いたばかりですので少し様子見です。

日経ベア売却

昨日売却注文を入れていた日本株逆連動投信が収穫されていました。
こちらは日経平均が下がった分だけ上昇する逆張りレバレッジをかけたような商品です。

8月末に日経平均さんが上昇して調子に乗ってたのでどうせ落ちると思って仕込んでいましたが、うまく利がのったようです。

日経平均の円建て価格だけ見ればもう少し落ちそうにも見えるのですがドル建てを見ると相当落ち込んでいるので、短期的には反発しそうです。
なので今度は普通のレバレッジ投信を仕込んで下がればナンピンしていくような感じにしそうです。

さて、日本株式は円安ブーストでしぶといですが、米国証券はボロボロになってきてますね。
去年末あたりに資産をある程度引き上げていたのでほぼ無傷だったのですが、6、7月の下落時に仕込んだ米国投信たちは含み損ゾーンに突入していきそうです。
複利効果もあるので中長期保有で放置すれば問題なさそうですが、短期的な反発で逃げ切れそうであれば利確するかもしれません。

今年以降は大局的に下落トレンドが続く見込みですので、短期と長期の視点で慎重な運用が求められそうです。
できる限り現金や債券比率を高めて買い場をじっくり待つのが賢明だとは思いますが、少しは運用しないとつまらないので欲望と恐怖の航海を続けていきます。

為替介入発動

www3.nhk.or.jp

政府と日銀が為替介入に踏み切ったようです。
この為替介入は国内のインフレ圧力要因の一つとなっている円安を「ドルを売り円を買う」ことによって押さえつける政策になります。より具体的には、国が保有する外貨資産を売却して円と交換(購入)する流れになります。

普段買っている食料品の値上がりに苦しんでいる身としては期待感もありますが、この為替介入にはいくつか注意点があります。

為替介入の限界

まず、実施できる為替介入には上限があるということです。為替介入で売却できる外貨資産は、イコール国が保有する(貯め込んだ)外貨資産の額面になります。
日本の外貨準備は1兆3000億ドル(185兆円)ですので、単純にこれが円買いの上限になります。加えて、国が保有する外貨資産の8割(1兆ドル)は外貨建て証券で、内訳の大半が米国債とみられています。つまり、政府が為替介入に踏み切った場合、米国債を売って円を買うという流れが中心になります。すると、米国債の価格が下落する(大量売却による需要低下)一方で米国債金利は上昇します。これは結果的に、日米金利差が拡大すること(日本は低金利のまま、米国金利が上昇する)を意味します。投資家は低金利から高金利に資産を映す傾向がありますから「円売りドル買いを始める」ことになります。この「円売りドル買い」は現在の円安の根本原因ですので、日本の為替介入が本末転倒の結果を招いた挙句、国の外貨準備を浪費するだけの結果に終わるという危うさも内包しています。

という見方もあるのですが、米国FRBのリバースレポファシリティーという仕組みを使えば米国債を担保としてドルを借り入れることができ、米国債の売却を回避(あとでドル払いで返せば担保の米国債が返却されます)できるため、上記のようなリスクは以前よりは低下しているとの情報もあります。

www.bloomberg.co.jp

外貨準備の喪失

為替介入で売却する外貨準備は、何の意味もなくため込んでいるわけでなく、通貨価値が暴落しても国際決済を行うための手段になります。
もう少しかみ砕くと、深刻な通貨安が進んだ状態における外貨建ての支払いが大きな財政負担となり困難となった際に、外貨資産による支払いは自国通貨安による影響を受けずに確実な決済ができる国家経済の防波堤として機能します。そのため、外貨準備が存在しない状態で通貨危機が発生した際にはデフォルト(国家破綻)のリスクが高まります。

最近の外貨準備の話題としては、ロシアへの経済制裁や韓国のウォン安が挙げられます。前者はウクライナ侵攻に伴ってドル決済から締め出されたことで外貨獲得の手段を失っている状況になります。結果的にロシア経済はドル建て支払いによる外貨準備の喪失や輸入制約に苦しんでいる状況になります。後者は、ウクライナ侵攻に伴う通貨安に対応するため、日本よりも先行して為替介入に踏み切った結果、外貨準備を強烈な側で喪失しているにも関わらずウォン安を止められていない状況になります。特に、空売りによってウォン安を誘導して、為替介入で上昇した差額分を利益とするため、国家予算並みの資金を持つ投資ファンドに標的とされ始めている点も気になるところです。

米国との外交摩擦

為替介入は国際的にタブーな手段とされているところも注意点といえます。これは、為替が輸出入の損益をはじめとして国家間の経済バランスに大きな影響力を持っていることが理由となります。例えば、輸出が盛んな国では自国通貨安を誘導することで、容易に貿易黒字を拡大することが可能です。一方、他国の為替介入によって割を食う国も発生してきます。すると、国家間で自国で有利な為替操作を競い合う競争が発生します。また、為替操作の能力は国家の経済規模に比例するため、このような競争が起これば、経済規模の小さい国家が追い込まれたり、お互いに外貨準備を消耗しあうような不毛な争いに発展します。このような理由で米国は為替介入を忌避する傾向がありますので、米国の同意がない日本政府による独断であった際には、外交摩擦に発展するリスクもあります。とりわけ、ドル安を誘導するということは米国が最も神経質になっている自国インフレに悪影響を及ぼす(輸入品の価格高騰など)懸念から反発される可能性もあります。
こちらについては、米財務省が「最近高まっている円のボラティリティー(変動性)の抑制を狙った行動だとしており、われわれはそれを理解した」と発表していて、それほど気にする必要はないかもしれません。

news.yahoo.co.jp

国内証券への影響

最後は、物価ではなく金融市場への影響ですので、資産運用していない方には関係ない内容になります。

こちらは日経平均の円建てとドル建てのチャートになります。一目瞭然ですが、ドル建て価格が下落しているのに対して、円建て価格はあまり下落していないことが分かります。
これは、ドル建て価格が急激な円安によって価値が目減りしていることを意味しています。別の見方をすれば、国外投資家からは日経平均が割安に見え、比較的資金が流入している状態といえます。
ここで、為替介入によって円高が加速した場合、ドル建て価格は上昇しますが海外投資家による売りが加速することで、円建て価格は下落することが予想されます。

このように株式や国債も為替と強い相関関係があり片方が変化すればもう片方も変化するといった影響があります。
実際にはここまで単純ではないと思いますが、こういった影響も予測できるようになると何気ないニュースの一面でしかない金融情報も理解に深みが出てくる気がします。

おわり

ここまで為替介入に関する妄想を垂れ流してきましたが、この政策自体が吉と出るか凶と出るかまではまったく分かりません。
ただ、家計や資産運用に直結していることは確かなので注視していきます。

ウクライナ戦況 Spearhead Operation

静かに見守っていたウクライナ戦況に大きな動きがありました。
機甲部隊の電撃作戦でロシア軍補給路の生命線ともいえる町を奪還し、ロシア軍を国外まで追い出すことに成功したようです。
進撃速度もさることながら情報統制や陽動で予兆を掴ませずに電撃戦を実現したのは見事というほかありません。

全体マップ


https://www.asahi.com/articles/ASQ9B031SQ99UHBI07B.html

こちらは全体マップですが、クピャンスクとイジュームという町が要所になります。

イジュームは首都キエフの制圧に失敗したロシア軍がルハンスク州やドネツク州を広範囲に包囲するための攻撃軸として重要な拠点となっていました。
ただし、ウクライナ軍の防御でこの包囲は叶わず、より狭い包囲としてセベロドネツクやリシチャンスクをめぐる戦いが7月頃に行われました。
現在、これらの町は制圧されスラビャンスクやバクムトが最前線となっていますが、激戦が続きながらも戦線は停滞しています。
最近のロシア軍は1週間に1kmしか進軍できていないとも言われています。

今回の主戦場となった北方のハルキウ方面も似たような状況が続いていて、反攻の予兆は全くありませんでした。

ヘルソン方面


https://militaryland.net/

ハルキウ方面の反攻前に注目されていたのは、南西部のヘルソン方面です。

ウクライナ軍は、NATO加盟国から提供されたロケット砲システムを使いこなして、兵站(弾薬庫や橋)を攻撃することでロシア軍を混乱させていました。
ハルキウ方面にはドニプロ川という大きな川が流れているため、渡河するためには3つの橋が重要になります。(図の×印がついたところです)
ウクライナ軍は、これらの橋を破壊してドニプロ川以西のロシア軍を孤立させて反攻作戦を開始しています。

ロシア側もこれに応戦して、東部から部隊を引き抜いてこちらに回しましたが、十分な物資が届けられない状況でうまく対応できていないようです。
さらに、対レーダーミサイルでロシア側の防空システムを破壊することでウクライナ側が航空優勢も確保しはじめています。

近代戦では空軍が陸軍に打撃を与えてから陸軍の攻勢をかけるのがセオリーになります。
一方、ウクライナ戦では、双方が相手の防空兵器を恐れて十分に空軍が運用できない状況が続いていました。
そのため、各戦線では、WW1のような塹壕戦や砲撃戦が繰り返されています。

対レーダーミサイルはこの戦況を打開するゲームチェンジャーの一つになっているようです。

ウクライナ軍の作戦としてはドニプロ川以西のロシアを駆逐するまでが目標と思われます。
理由は橋を破壊しているためにその先には進めないものの、川を挟むことで防御が容易になり、より少ない戦力で戦線を維持することが可能になるためです。

ドニプロ川まで戦線を押し返した段階で他戦線に戦力を集中するのかと考えていましたが、ハルキウ方面の反攻は全くの予想外でした。

ハルキウ方面

今回の「Spearhead Operation」と呼ばれるハルキウ反攻作戦では、今まで温存した大規模な機甲部隊を投入することでロシアの防衛線を食い破りクピャンスクという町を中心として、ロシア軍の兵站網を崩壊させました。この町は前述のロシア本国からイジュームやセベロドネツクに物資を輸送する重要拠点であり、ここを失うと補給先地域の部隊は孤立します。さらに、本来想定していなかった方向から陣地が攻撃・包囲される脅威にもさらされ、大混乱に陥ったようです。
以下は反攻の流れです。

今回突破したロシア軍防衛線は、南部方面に部隊を引き抜かれていたため、スカスカな状態でした。
ウクライナ軍としても活発に偵察を行いこの状況を掴んでいたようです。
さらにロシア側は攻撃されることを想定した防御態勢が準備されておらず、ほとんど応戦できないという悲惨な結果になりました。
武器弾薬もほったらかしのまま撤退しているため、鹵獲装備も山のようにあるとのことです。

ウクライナ側の兵站もあるのでどこかで落ち着くでしょうが、戦況が好転したのは間違いなさそうです。
引き続き今後の行方を見守りたいと思います。

個別株投資:メルカリ編

最近はインデックス投資に慣れてきたので余剰資金で個別株にも手を出してみました。

こちらはメルカリ株の評価損益

株価が急落して落ち着いた(ように見えた)ところで買って放置していましたが、現状は含み益が出ている状態です。(ただの含み益なので今後の動向によっては消し飛ぶかもしれません)
個別株を触った感触としてはやはりインデックス投資よりも運用が難しいと感じました。

個別株は企業の事情だけでなく、社会情勢や大型投資家の都合にも左右されているため、正確な予測がつきません。
購入した当初も売られまくっているのでそろそろ大丈夫でしょ、という適当なノリでしたが、振り返るとこのチャートにもいくつかのドラマが含まれていたようです。

#私はド素人なのでチャート分析や企業分析は他者の受け売りです。(ソースはゆーちゅーぶ)

地合いとヘッジファンドの謀略

メルカリ株は去年の年末には7000円を超えてグロース株の主力銘柄に君臨していましたが、4月頃までに半額以下の3000円程度まで急落しています。
どうやらこれは、年末から続くグロース株全体の下落に巻き込まれてしまっただけのようです。そのため、企業の問題ではなくグロース市場全体の下落トレンドの影響と言えます。

しかし、ここにヘッジファンドの謀略が隠れていて株価がさらに下落するというイベントがあったようです。

まず、3000円程度でも割安感が出ていたため、個人投資家は上昇を見越して信用買いをしました。それらを察知したヘッジファンドは大量の空売りを仕掛けることで、さらに株価を急落させました。
ヘッジファンドの資産力は個人投資家を大きく上回るため、買い圧力を売り圧力で押しつぶし、損切をさせることでこれを実現したようです。
一言でいうと個人投資家ヘッジファンドの養分になったという構図です。


不正利用、決算発表

株価が急落した要因は外的要因でしたが、株価の重しとなっているのが今年度の決算発表です。
具体的にはクレジットカードの不正利用の賠償が利益を圧迫しているとのことで、赤字が続いているという内容です。

悪用の内容も確認すると、盗難されたクレジットカード情報を利用して商品の受渡しが円滑なゲームのDLソフトを売買して、資金洗浄が行われたようです。
これは認証や不正判定の処理が甘く、窃盗アカウント上で窃盗クレジットカードを使用する、さらに住所情報や電話番号などの個人追跡情報が一切残らない取引を利用する、といったことが可能であったためと考えられます。

このような手法は盗難されたクレジットカードの資金を抽出して、個人情報と紐づいていない別の資産に変換するCardingと呼ばれるテクニックで、他にも決済サービスやゲームの課金要素を踏み台にするなど様々な方法が使われています。
犯罪者側は、決済通過や身元隠蔽を重視するため、これらを阻害するような対策が十分取られていなかった点では、企業側の問題であり評判を下げる一因になったと考えられます。

おわりに

不正利用以外にも転売問題があることを考えると、フリマアプリには法整備の問題など課題が多そうです。
ただ、株価に限って言えば悪材料が出尽くしていますし、技術面は素晴らしい会社だと思うので今後の爆上げ昇竜拳を期待しています。

個別株のチャートを追いかけるのも面白かったのですが、会社ごとにこれをやるのはしんどすぎるので、インデックス投資が安定だと思いました。

CIS Software Supply Chain Security Guideの紹介

今回のテーマは最近よく耳にするサプライチェーン
後半では、Cloud Native Security Conference 2022で知ったCIS Software Supply Chain Security Guideを紹介。


サプライチェーンセキュリティの背景

サプライチェーンという用語は、一般的に何らかの製品の生産、物流、販売などの一連のフロー全体を意味します。
一方、サプライチェーンは様々なコンテキストで語られるため、具体的な定義は対象やスコープによって大きく異なります。
例えば、小麦の生産→購買、工業製品の生産→購買では、前者の生産が天候に大きく影響を受けるの対して、後者への影響は限定的と言えます。
このように対象が異なればサプライチェーンの特性やリスクも異なります。

さて、IT業界の製品やサービスを構成する要素には主に以下のようなものが挙げられます。
比重自体はアーキテクチャ(IoT、モバイルアプリ、webアプリ)や業種(SIベンダ、ソフトウェアベンダ、サービスベンダ、通信事業者)によって様々かと思いますが、大雑把にはこれらに属すると思われます。
・自社開発ハードウェア
・自社開発ソフトウェア
OSSオープンソースソフトウェア)
・他社調達製品(ハードウェア、ソフトウェア)
・他社クラウドサービス

ここでIT製品のサプライチェーンでは、自社製品から他社製品、それらの生産に関わるモノやヒトまで、保護対象(脅威)領域には際限がありません。
例えば、他社製品の調達と言っても、供給元におけるソフトウェアの脆弱性診断、サーバルームの監視カメラ、従業員のソーシャルエンジニアリング対策など、技術、物理、運用の観点から様々な対策が求められます。その上、調達元が複数となればアタックサーフェスは増加していきます。

このようにサプライチェーンの範囲は挙げればキリがなく、議論の際はスコープ絞りが必要になります。
Cloud Native Security Conference 2022の講演にもあるとおり、サイバーセキュリティの分野では下記のようなコンテキストで語られることが多いようです。

一つは委託先や関連会社などの「社外」対策、もう一つは社内でのソフトウェア開発やシステム開発などの「社内」対策といえます。
前者は後者よりもガバナンスを利かせにくいため、特に対策が難しいとされています。ただ、万事休すというわけでなく、NIST SP 800 171への対応といったアプローチが取られています。
NIST SP 800 171については詳しく言及しませんが、概要としては米国連邦政府や関連組織にシステムを納品する供給組織が守るべきセキュリティ基準になります。
サプライチェーンに関わる組織が遵守することで「一次受けは対策をしているが二次受け以降はガバガバという状況」を緩和できるとされています。防衛省でもこちらを採用していたはずです。

さて、「社外」対策と「社内」対策では、まずは組織内で実施できる範囲からになると思います。
初歩的なアプローチとしてはISMS情報セキュリティマネジメントシステム)準拠のように、メジャーなガイドラインに沿って組織のセキュリティ体制を強化することになるでしょう。
ただし、ソフトウェア成果物が依存する外部ライブラリや有償製品の対策では、脆弱性対策のように手が回らないところが出てきます。
このような課題を解決するために、ソフトウェアの開発プロセスをよりセキュアにする(より安全なソフトウェアをデリバリする)「Software Supply Chain Security」という分野が提唱されています。

整理すると、まず広義の「Supply Chain Security」があり、脆弱な関連組織自体を狙う「Island Hopping Attack」や自社ソフトウェアが依存するコンポーネントを狙う「Software Supply Chain Attack」に対してそれぞれ対策アプローチがあることになります。

今回テーマのCIS Software Supply Chain Security Guideは主に後者のガイドラインになります。


CIS Software Supply Chain Security Guide

「Software Supply Chain Security」の先駆的な取り組みとしてSLSA(SLSA • Supply-chain Levels for Software Artifacts)やSoftware Supply Chain Best Practices(tag-security/CNCF_SSCP_v1.pdf at main · cncf/tag-security · GitHub)がありますが、最近CIS Software Supply Chain Security Guide(chain-bench/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf at main · aquasecurity/chain-bench · GitHub)なるものが登場したようです。

確認したところ、100 を超える推奨事項がありそれなりのボリュームです。
ただ、SLSAやCNCFのガイドラインと比較してそれほど目新しいものはないように感じました。(見たことある内容もちらほら)

下記は推奨事項の一例です。

カテゴリ 対策例
Source Code バージョン管理プラットフォームでコードの変更を追跡する
Source Code コードへの変更が 2 ⼈の強力に認証されたユーザーの承認を確実に受けるようにする
Source Code マージ前に新しい変更の署名済みコミットを確認する
Source Code IP アドレスに基づいて Git アクセスが制限されていることを確認する
Source Code ブランチ保護ルールが管理者に適⽤されていることを確認する
Source Code コード内の機密データを識別して防⽌するためのスキャナーが配置されていることを確認する
Source Code 継続的インテグレーション (CI) パイプライン命令を保護するためにスキャナーが配置されていることを確認する
Source Code Infrastructure as Code (IaC) 命令を保護するためにスキャナが配置されていることを確認する
Source Code コードの脆弱性を検出するスキャナーが配置されていることを確認する
Source Code 使⽤されているパッケージのオープンソース脆弱性に対してスキャナーが配置されていることを確認する
Source Code 使⽤済みパッケージのオープンソース ライセンスの問題に対してスキャナーが配置されていることを確認する
Build Pipelines 各パイプラインに単⼀の責任があることを確認する
Build Pipelines パイプライン インフラストラクチャと構成のすべての側⾯が不変であることを確認する
Build Pipelines ビルド環境の作成が⾃動化されていることを確認する
Build Pipelines ビルド環境へのアクセスを制限する
Build Pipelines ビルド ワーカー環境とコマンドが渡され、プルされていないことを確認する
Build Pipelines 各ビルド ワーカーの職務が分離されていることを確認する
Build Pipelines ビルド ステージの⼊力と出力がステップで明確に定義されていることを確認する
Build Pipelines 出力が別の安全なストレージ リポジトリに書き込まれるようにする
Build Pipelines すべてのリリースのすべての成果物が署名されていることを確認する
Build Pipelines パイプラインのすべての依存関係を検証する
Build Pipelines ビルド パイプラインが再現可能なアーティファクトを作成することを確認する
Build Pipelines パイプラインのステップでソフトウェア部品表 (SBOM) が確実に作成されるようにする
Build Pipelines ⽣成された SBOM にパイプライン ステップが署名することを確認する
Dependencies サードパーティアーティファクトオープンソース ライブラリが検証されていることを確認する
Dependencies すべてのサードパーティ サプライヤから SBOM が要求されていることを確認する
Dependencies オープンソース コンポーネント間の依存関係を確実に監視する
Dependencies コードの署名済み SBOM が提供されていることを確認する
Dependencies 既知の脆弱性についてパッケージが⾃動的にスキャンされるようにする
Artifacts すべてのアーティファクトがビルド パイプライン⾃体によって署名されていることを確認する
Artifacts アーティファクトが配布前に暗号化されていることを確認する
Artifacts 許可されたプラットフォームのみがアーティファクトの復号化機能を備えていることを確認する
Artifacts パッケージ レジストリのアップロード時に、すべての署名済みアーティファクトが検証されていることを確認する
Artifacts 既存のアーティファクトのすべてのバージョンの署名が検証されていることを確認する
Artifacts 成果物にその起源に関する情報が含まれていることを確認する
Artifacts プライベート アーティファクトを外部レジストリから取得できないようにする
Deployment デプロイメント構成ファイルがソース コードから分離されていることを確認する
Deployment デプロイメント構成の変更が確実に追跡されるようにする
Deployment デプロイ中の機密データを特定して防⽌するためのスキャナーが配置されていることを確認する
Deployment デプロイ構成へのアクセスが特定のメンバーに制限されていることを確認する
Deployment デプロイ構成マニフェストが検証されていることを確認する
Deployment デプロイが⾃動化されていることを確認する
Deployment デプロイ環境が再現可能であることを確認する

自組織の開発者に責任のあるソースコードの対策としては、ソースコード管理ツールのアクセス制限や署名、脆弱性診断などが挙げられています。
サプライチェーン固有というよりは一般的な内容が多い気がします。その他は、依存ライブラリ、サードパーティ製品の対策に加えて、CI(Continuous integration)技術やIaC(Infrastructure as Code)技術まで意識された内容になっています。

ここで特に注目されるべきは、「署名」や「脆弱性診断」といったキーワードに対応するAttestations技術やSBOM技術になります。

Attestations技術

開発フロー上で成果物の改ざんが行われると開発環境にとどまらず本番環境まで侵害リスクが及びます。
そこで、ソースコードから成果物、果ては「だれがどこで何をしたかそれらを証明する」に至るまで、あらゆる箇所で証明書や暗号ハッシュを用いて、真正性を確保することが推奨されます。
極限までこれらをサポートする実装例がCNCFのin-totoになります。実装は下記で紹介されていますが、正直ここまでやるか。。というような内容です。

ソフトウェア・サプライチェーン・インテグリティ保証ツール in-toto の紹介 - Qiita

SBOM技術

依存ライブラリ、サードパーティ製品のような他組織で開発されたパッケージは内部構成を把握しきれないことに起因して、脆弱性を見落とすことがあります。
例として、「Apache Log4j」のように開発者が何らかのjavaパッケージをインストールした際に意識せずに取り込まれたコンポーネント脆弱性が見つかるケースがあります。
運用中システムの脆弱性検出は、大前提として構成管理されたパッケージ名やバージョン情報を脆弱性データベースと照合して行われます。
そのため、従来は構成管理の粒度が荒く、記録されていない内部コンポーネント脆弱性までは見落とされやすかったということになります。

そこで登場したのがSBOM(Software Bill of Materials)です。
SBOMはパッケージ単位で依存パッケージやコードスニペットを管理するため、うまく活用することで前述のようなリスクを軽減することが期待されています。
具体的な内容は触れませんが、実装例のSPDXフォーマットについてはこちらで詳しく解説されています。

SPDX Documentを理解する|OSS管理ブログ|オープンソース管理ソリューション|日立ソリューションズ

chain-bench

CIS Software Supply Chain Security Guideのチェックツールであるchain-benchもあるようですが、まだ対応項目が少なそうな印象を持ちました。

CIS 1.0 | Vulnerability Database | Aqua Security

おわり

概要レベルですが、改ざん検知や脆弱性検知を強化することで、より信頼できる開発プロセスを実現していく「Software Supply Chain Security」の紹介でした。