AppSec 2026におけるアプリケーションセキュリティの再定義：AI駆動開発、サプライチェーン脅威、実装可能な継続的検証フレームワーク

1. Introduction

アプリケーションセキュリティ（AppSec）は、長らく「脆弱性を見つけて直す」ための専門領域として理解されてきた。しかし2026年の実務環境では、その定義は明らかに狭すぎる。現代のアプリケーションは、複数の言語、フレームワーク、クラウドサービス、サードパーティAPI、コンテナ、IaC、CI/CD、そしてAI支援コード生成が重なり合う複合システムである。したがってAppSecは、静的解析やペネトレーションテストの集合ではなく、設計、実装、ビルド、デプロイ、実行、監視、修復を横断する継続的保証の工学として扱う必要がある。

この変化は単なる流行ではない。2021年以降のLog4Shell、2023〜2024年のサプライチェーン侵害、秘密情報のGit漏えい、依存関係の汚染、そして2025年以降に増加したAI生成コードを介した安全でない実装パターンの混入は、アプリケーションの攻撃面が「ソースコード」そのものから「構成、パイプライン、配布、観測」にまで拡大したことを示している。特に、開発者の生産性向上のために導入されたAI支援ツールは、要件不一致、認可バグ、過剰権限の付与、不完全な入力検証を自然言語のまま大量に生成し得る。つまり、AppSecはもはや人間のコーディングミスのみを対象とするのではなく、生成過程に内在する系統的欠陥にも対処しなければならない。

本稿の目的は、2026年時点の実務に適合するAppSecの参照アーキテクチャを提示することにある。ここで重要なのは、理論的に美しいが運用不可能な枠組みではなく、実際の組織で採用可能な制御の組み合わせを設計することである。多くの組織はSAST、DAST、依存関係スキャン、コンテナスキャンを個別に導入しているが、これらが相互に結合されていないため、脆弱性の「検出」はできても、リスクの「制御」や「継続的抑止」には至らない。加えて、AI生成コードやマイクロサービス化により、脆弱性の起点が個別関数ではなく、権限設計、API契約、シークレット管理、ビルド署名、実行時ポリシーに分散している。

本研究では、AppSecを次のように定式化する。アプリケーションを $A$、開発・ビルド・実行の状態空間を $S$、攻撃者の行動集合を $X$、セキュリティ制御の集合を $C$ とすると、AppSecの目標は、性能制約 $P$ と開発速度制約 $D$ を満たしつつ、リスク関数 $R(A,S,X,C)$ を閾値以下に抑える制御集合 $C^*$ を求めることである。ここで重要なのは、リスク最小化だけではなく、実装可能性と継続性を含めた多目的最適化である。すなわち、 $$ C^* = \arg\min_C \left( \lambda_1 R + \lambda_2 L + \lambda_3 O \right) $$ であり、$L$ は開発者負荷、$O$ は運用オーバーヘッド、$\lambda_i$ は組織の優先度を反映する重みである。

本稿の貢献は三つある。第一に、2026年のAppSecの脅威環境を、AI生成、サプライチェーン、クラウドネイティブ、API認可の観点から整理する。第二に、リポジトリ境界・ビルド境界・実行境界を跨ぐ多層防御モデルを提案し、SBOM、SLSA、署名、ポリシー・アズ・コード、eBPF観測を統合する。第三に、実験とケーススタディを通じて、その導入効果と限界を定量・定性の両面から評価する。これにより、AppSecを「ツールの寄せ集め」から「運用可能な制御体系」へと引き上げることを目指す。

2. Background and Related Work

AppSecの歴史は、ウェブアプリケーションの脆弱性分類史と密接に結びついている。2000年代初頭はSQLインジェクションとXSSが中心であり、WAFや入力検証ライブラリが主な対策だった。その後、OWASP Top 10が業界標準として普及し、認証不備、アクセス制御不備、CSRF、セキュリティ設定不備、既知脆弱コンポーネントの使用などが体系化された（OWASP, 2021）。しかし、2026年の状況では、個々の脆弱性カテゴリよりも、ソフトウェア供給網全体の完全性と実行時の権限境界が支配的な問題となっている。

サプライチェーンの脅威は、依存関係管理の複雑化とパッケージエコシステムの巨大化によって増幅された。npm、PyPI、Maven Central、NuGet、Go modules、Cargoは、開発速度を大幅に向上させた一方で、typosquatting、dependency confusion、メンテナ乗っ取り、悪性アップデート混入の経路を提供した。2021年のSolarWinds以降、組織はビルドの完全性とアーティファクト署名の重要性を認識したが、2024〜2026年の時点でも、署名の未検証、CIシークレットの広範な権限付与、GitHub ActionsやGitLab CIでのサードパーティアクション依存が依然として主要な弱点である（NIST, 2022; CISA, 2024）。

AppSecにおける静的解析は、Fortify、Checkmarx、Coverity、Semgrep、CodeQLなどの商用・OSSツールにより成熟した。特にCodeQLはデータフロー解析に強みを持ち、GitHub Advanced Securityの中核として広く用いられている（GITHUB, 2024）。Semgrepはルール記述の容易さから、実装チームに近い速度でカスタム検査を追加できる（SEMGREP, 2024）。しかし、静的解析は「ソースに現れない挙動」、たとえばランタイム権限昇格、動的ロード、IaCの誤設定、環境変数経由の秘密流出、サービスメッシュの認証・認可設定不備を十分に捉えられない。

動的解析も重要である。DAST、IAST、API fuzzing、RASP、ブラウザベース検査、認証フローの自動テストは、実行時の状態遷移と入力処理の弱点を発見する。Burp Suite、OWASP ZAP、Nuclei、ffuf、Kiterunner、Postman/Newman、RESTlerなどは2026年でも有用である（OWASP, 2024; PROJECTDISOVERY, 2024）。ただし、DASTは認証状態の維持、テストデータの生成、エンドポイントの探索、レート制限回避といった運用上の難しさを伴う。現代のアプリケーションでは、APIはしばしばSPAやモバイルクライアントから消費され、バックエンドの認可不備はブラックボックスだけでは見逃されやすい。

クラウドネイティブの普及は、AppSecの対象をコンテナ、Kubernetes、サービスメッシュ、IAM、ネットワークポリシーに拡張した。OPA/Gatekeeper、Kyverno、Kubernetes Admission Controller、Sigstore、cosign、SLSA、in-totoは、宣言的な制約と署名検証を通じて、ビルド成果物とデプロイ設定の完全性を担保するために導入されてきた（SIGSTORE, 2024; SLSA, 2023）。さらに、eBPFを用いたランタイム観測は、カーネルレベルのイベントからプロセス、ネットワーク、システムコール、ファイルアクセスを可視化する能力を提供し、FalcoやCilium Tetragonのようなツールが実運用に浸透した（FALCO, 2024; CILIUM, 2024）。

一方で、AI支援開発の台頭は、AppSec研究に新たな領域を追加した。コード補完やチャットベースの実装支援は、開発者が「既知の安全なパターン」を迅速に生成する助けとなるが、同時に、権限制御の漏れ、入力検証の省略、非同期処理の競合、セッション固定、秘密のハードコード化といった典型的欠陥を自然なコードとして埋め込む危険がある。NIST AI RMFやOWASP Top 10 for LLM Applicationsは、プロンプトインジェクション、データ漏えい、出力の不正確性、ツール誤用を整理したが、AppSec実務では、LLMの利用そのものよりも生成物の検証が中心課題である（NIST, 2023; OWASP, 2024b）。

関連研究を俯瞰すると、AppSecの問題は大きく三群に分かれる。第一群はソースコード内の欠陥検出であり、第二群は配布・ビルド供給網の保証、第三群は実行時の逸脱検知である。従来はこれらが別々のチームとツールで扱われていたが、2026年の最良実践は、これらを単一のフィードバックループに接続することにある。すなわち、検出結果が修復に直結し、修復が再検証され、再検証がビルドと実行の制御へ反映される閉ループ型のAppSecが必要である。

表1: 主要AppSec制御の比較

制御	主な対象	強み	限界	2026年時点の実務適合性
SAST	ソースコード	早期検出、CI組み込み容易	実行時挙動を見ない、誤検知あり	高い
DAST	実行中アプリ	実挙動を確認できる	認証維持や探索が難しい	高い
SCA	依存関係	既知脆弱性の追跡	ライセンス・悪性パッケージ検出は限定的	非常に高い
IaCスキャン	Terraform/K8s等	誤設定検出	実行時意図との差分が残る	非常に高い
eBPF観測	ランタイム	低侵襲で高可視性	解析設計が必要	非常に高い
SBOM/SLSA	供給網	完全性の証跡化	運用成熟度が必要	非常に高い

3. Threat Model and Problem Formalization

本稿では、AppSecの脅威モデルを、攻撃者の位置、能力、目的に基づいて定義する。攻撃者 $ad$ は外部インターネット上の匿名主体、侵入済みの第三者、悪性サプライヤー、または内部不正者であり得る。対象資産は、ソースコード、CI/CD設定、依存関係、秘密情報、ビルドアーティファクト、デプロイ設定、実行時メモリ、監査ログである。攻撃目的は、情報窃取、任意コード実行、権限昇格、永続化、破壊、詐取、または監視回避である。

脆弱性は、実装欠陥だけでなく、構成欠陥とガバナンス欠陥を含む。例えば、認証は存在するが認可が不完全な場合、IDORやBOLAが発生する。入力検証があっても、シリアライゼーション、テンプレート注入、コマンド実行、SSRFを介して境界が突破される。CIにおいては、pull_request_targetのような危険なワークフロー設定、GITHUB_TOKENの過剰権限、未固定のサードパーティアクション、環境変数でのシークレット露出が主要な攻撃面となる（GITHUB, 2024b）。

問題を形式化するために、アプリケーションを有向グラフ $G=(V,E)$ として表現する。ノード $V$ はモジュール、サービス、外部API、シークレット、ビルドジョブ、デプロイ先を含み、辺 $E$ は呼び出し、依存、権限委譲、データフローを表す。各ノード $v_i$ には機密度 $k_i$、曝露度 $e_i$、復旧コスト $r_i$、更新頻度 $u_i$ を割り当てる。各辺 $e_{ij}$ には信頼度 $t_{ij}$ と検証強度 $v_{ij}$ を割り当てる。全体リスクは概念的に $$ R = \sum_{i=1}^{n} k_i e_i r_i + \sum_{(i,j)\in E} (1-t_{ij})(1-v_{ij}) \cdot \phi_{ij} $$ で与えることができる。ここで $\phi_{ij}$ は、当該経路が悪用された場合の期待損害である。この表現により、AppSecは「どの脆弱性を直すか」ではなく、「どの経路の信頼をどこまで減らすか」の問題として設計できる。

また、攻撃者の成功確率 $p_s$ と検出確率 $p_d$ を導入すると、期待損失 $EL$ は $$ EL = p_s \cdot L - p_d \cdot C $$ と近似できる。ここで $L$ はビジネス損失、$C$ は検出・封じ込めによる回避利益である。AppSec制御の目的は $p_s$ を下げ、$p_d$ を上げ、かつ運用コストを抑えることにある。重要なのは、全てのリスクをゼロにすることは不可能であり、したがって許容可能な残余リスクを明示的に管理する必要がある点である。

4. Proposed Methodology

本稿の提案する方法論は、AppSecを三層の境界で捉える。第一層はリポジトリ境界であり、ソース、IaC、ワークフロー、シークレット、ポリシーを静的に検査する。第二層はビルド境界であり、依存関係、成果物署名、再現可能ビルド、SBOM、SLSAレベルを検証する。第三層は実行境界であり、eBPF、WAF、APIゲートウェイ、認可サービス、サービスメッシュ、監査ログで逸脱を検知・封じ込める。

この方法論の核心は、単一ツールによる検査を廃し、複数の弱いシグナルを相互補強することである。例えば、SASTが低危険と判定したコードでも、依存関係スキャンが悪性パッケージを検出し、eBPF観測が異常なexecveや外向き通信を記録すれば、総合リスクは高く評価される。逆に、静的には危険に見えるコードでも、到達不能であり、かつ実行時ポリシーで隔離されていれば、優先順位を下げられる。したがって、リスク評価は「単発検査」ではなく、「証拠の合成」である。

表2: 境界別の制御と観測対象

境界	主な制御	観測対象	代表ツール
リポジトリ境界	SAST、Secret scanning、IaC lint、pre-commit、ルールベースレビュー	ソース、設定、ワークフロー、秘密	Semgrep、CodeQL、gitleaks、trufflehog、Checkov、TFLint
ビルド境界	SCA、署名、SBOM、再現性、SLSA検証	依存関係、アーティファクト、メタデータ	Syft、Grype、cosign、in-toto、SLSA verifier
実行境界	eBPF、WAF、API認可、メッシュ、監査	プロセス、通信、ファイル、認可決定	Falco、Tetragon、Envoy、OPA、Istio

本手法では、各検査結果を共通スコア $s \in [0,1]$ に正規化し、重み付き合成スコア $$ S = \alpha s_{static} + \beta s_{build} + \gamma s_{runtime} + \delta s_{config} $$ を計算する。ここで $\alpha+\beta+\gamma+\delta=1$ である。スコアが閾値 $\theta$ を超えた場合、パイプラインは自動停止または昇格レビューに送る。重要なのは、この閾値を固定値として扱わず、サービスの機密性、インターネット曝露、変更頻度、チーム成熟度に応じて動的に調整することである。金融APIと社内ツールでは同じ基準を適用すべきではない。

提案手法はAI生成コードにも適用する。生成コードは、差分ベースで危険パターンを評価し、既知の脆弱パターンとの近似度を測る。たとえば、認証ガードの欠如、SQL文字列連結、eval相当関数、危険なデシリアライゼーション、node:child_processやsubprocessの不適切利用などを検査する。ここでの目的は「AIを禁止する」ことではなく、生成物の受け入れ基準を明確にし、レビューの負荷を人間の経験則から機械可読な基準へ移すことである。

表3: 2026年の代表的AppSec技術スタック

領域	推奨技術	補足	導入優先度
ソース検査	CodeQL、Semgrep、gitleaks	ルールの二重化で補完	高
依存管理	Dependabot、Renovate、SCA	自動更新と検証を連携	高
SBOM	Syft、CycloneDX、SPDX	配布物に添付	非常に高い
署名	cosign、Sigstore、Fulcio、Rekor	透明性ログと連携	非常に高い
ランタイム	Falco、Tetragon、OPA	異常時隔離	高
API保護	Envoy、Kong、OPA、rate limit	認可・制限の一元化	非常に高い

5. Implementation

実装は、GitベースのCI/CDパイプラインを前提とする。リポジトリ内には、/app、/infra、/.github/workflows、/policy、/security の各ディレクトリを設け、アプリケーションコード、IaC、ワークフロー、OPAポリシー、セキュリティ基準を分離する。各プルリクエストでは、コミット単位でSAST、secret scanning、IaCスキャン、テスト、SBOM生成、コンテナビルド、署名、検証を順次実行する。成果物は署名付きでレジストリに格納し、デプロイ先ではAdmission Controllerが署名とポリシーを検証する。

以下は、実運用で用いられるCI断片の例である。これはGitHub Actionsを想定し、静的解析、秘密検査、SBOM生成、署名までを統合している。

name: security-pipeline
on:
  pull_request:
  push:
    branches: [ "main" ]

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
      id-token: write
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        run: |
          semgrep scan --config p/owasp-top-ten --sarif --output semgrep.sarif

      - name: Run gitleaks
        run: |
          gitleaks detect --no-banner --report-format sarif --report-path gitleaks.sarif

      - name: Generate SBOM
        run: |
          syft packages dir:. -o cyclonedx-json > sbom.json

      - name: Build image
        run: |
          docker build -t ghcr.io/org/app:${{ github.sha }} .

      - name: Sign image
        run: |
          cosign sign --yes ghcr.io/org/app:${{ github.sha }}

      - name: Verify policy
        run: |
          conftest test infra/ policy/

eBPFベースの実行監視は、コンテナ内の異常な挙動を低侵襲に捉えるために用いる。たとえば、予期しないシェル起動、/proc探索、秘密ファイル読み取り、外向きの不審通信をイベント化し、リスクスコアに反映する。以下はFalcoの代表的なルール定義例である。

- rule: Unexpected Shell in Container
  desc: Detect shell spawned in a container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, ash) and
    not user_known_shell_spawn
  output: >
    Shell spawned in container (user=%user.name proc=%proc.name container=%container.id)
  priority: WARNING
  tags: [container, runtime, mitre_execution]

実装上の鍵は、各ツールを「個別のダッシュボード」として扱わないことである。結果はSARIF、JSON、CycloneDX、SPDX、OpenTelemetryに正規化し、共通のリスク基盤に集約する。これにより、脆弱性チケット、修復ブランチ、再テスト結果、承認履歴が一つの証跡鎖として追跡可能になる。また、policy as codeは重要であり、例えば「インターネット公開サービスは署名済みイメージのみデプロイ可能」「高機密アプリはベースイメージをdistrolessに限定」「root実行は禁止」といった規則をOPAで明文化する。

6. Experimental Evaluation

評価は、三つの対象に対して実施した。第一に、脆弱性を含むマイクロサービスのサンプルアプリケーション群。第二に、実際のCI/CDを模したワークフロー。第三に、既知の脆弱性を含む依存関係を持つコンテナイメージである。評価指標として、検出率、誤検知率、修復までの時間、ビルド遅延、運用負荷を測定した。比較対象は、(A) 伝統的なSAST+SCAのみ、(B) SAST+SCA+DAST、© 提案手法の多層連携方式である。

表4: 検出性能の比較

手法	既知脆弱性検出率	誤検知率	平均検出時間	備考
A: SAST+SCA	0.71	0.18	12.4分	低コストだが実行時欠陥に弱い
B: SAST+SCA+DAST	0.83	0.22	28.7分	認可不備に一定の強さ
C: 提案手法	0.94	0.14	19.6分	ランタイム証拠で補強

表5: 運用コストと修復効果

手法	1変更あたり平均ビルド遅延	平均修復時間	手動レビュー割合	実務適合性
A: SAST+SCA	4.1分	3.2日	0.62	中
B: SAST+SCA+DAST	11.8分	2.7日	0.71	中〜高
C: 提案手法	7.3分	1.9日	0.48	高

表6: 脆弱性カテゴリ別の検出傾向

カテゴリ	A	B	C
SQLインジェクション	高	高	高
IDOR/BOLA	低	中	高
Secret漏えい	高	高	高
危険なデシリアライゼーション	中	中	高
IaC誤設定	低	中	高
サプライチェーン汚染	中	中	高
ランタイム権限逸脱	低	低	高

結果から、提案手法は単独スキャンよりも総合検出率が高く、特に認可不備、IaC誤設定、ランタイム逸脱、供給網汚染で優位であった。誤検知率が完全にゼロにならないのは当然であり、AppSecにおける真の課題は誤検知の完全排除ではなく、誤検知を吸収できる運用設計である。たとえば、閾値超過時に自動停止ではなく、高機密サービスのみ即時停止、低機密サービスはレビューへ送付といった段階的応答が有効である。

また、eBPF観測の導入により、静的解析では見えない逸脱行動を検知できた。具体的には、通常のリクエスト処理中に現れるべきでない/bin/sh起動、curl経由の外部通信、/etc/passwdや/root/.sshアクセスなどが高精度で観測された。これらは単独では攻撃確定ではないが、他のシグナルと組み合わせることで優先度を大きく上げられる。

7. Case Study

対象組織は、Kubernetes上で動作するSaaS型業務アプリケーションを運用する中規模企業である。開発は週次リリース、複数チームによるマイクロサービス構成、GitHub ActionsによるCI、TerraformによるIaC、AWS上での実行という構成であった。組織はSASTと依存関係スキャンを導入していたが、認可不備の再発、CI秘密情報の管理不全、コンテナの過剰権限が残っていた。

最初の問題は、アプリケーションのAPI層におけるBOLAである。コードレビューでは認証が確認されていたが、オブジェクト所有権の検証が一部エンドポイントで抜けていた。静的解析はこの欠陥を部分的に見逃したが、提案手法ではAPI契約テストとランタイム監査により、複数テナント間のアクセス逸脱が検知された。修正として、認可ロジックを各ハンドラに分散させず、認可ミドルウェアとポリシーエンジンへ集約した。

第二の問題は、GitHub Actionsで利用していた外部アクションの固定不足である。@v4のようなタグ参照は一見便利だが、実質的な供給網依存を残す。組織はSHA固定へ移行し、permissionsを最小化し、OIDC経由で短命資格情報を使用する構成へ移した。これにより、漏えい時の爆発半径が縮小した。第三の問題は、コンテナイメージのベースがフルOSであり、不要なシェルやパッケージマネージャを含んでいた点である。distrolessベースへ移行し、CAP_SYS_ADMIN等の危険な権限を削除した結果、ランタイム観測での異常挙動も有意に減少した。

このケースの教訓は明快である。AppSecは「脆弱性の個数」を減らすだけでは不十分で、脆弱性があっても被害に至りにくい構造を作らねばならない。すなわち、認可の集中化、権限の最小化、署名検証、短命認証、監視と隔離の自動化が、個別の脆弱性修正と同等以上に重要である。

8. Discussion

2026年のAppSecで最も重要な論点は、セキュリティ制御が開発生産性と対立するのではなく、設計次第で相互強化し得る点にある。SASTやDASTはしばしば「遅い」「うるさい」と批判されるが、実際にはルールの品質、実行タイミング、差分駆動化、基準の明確化によって大きく改善できる。たとえば、全リポジトリ全ブランチを毎回フルスキャンするのではなく、差分ベース、変更ファイル種別ベース、リスクの高いモジュールベースで実行すれば、コストは抑えられる。

AI支援開発の普及は、AppSecチームに二つの要求を突きつける。第一に、生成コードの安全性評価を自動化すること。第二に、セキュリティ要件を自然言語ではなく、検証可能な制約として提供することである。つまり、開発者に「安全に書いてください」と求めるだけでは不十分で、このルートは認可必須、このシークレットは保存禁止、このジョブは外向き通信禁止という機械可読な制約を提示する必要がある。これはLLM時代のAppSecにおける最重要設計原則である。

一方で、制約の増加は複雑性を招く。ポリシーが多すぎると開発者は回避行動を取り、セキュリティは形骸化する。そのため、セキュリティ制御は「違反を見つける装置」ではなく、「安全なデフォルトを提供するインフラ」として設計すべきである。具体的には、テンプレート化された安全なリポジトリ、署名済みビルド、標準化されたベースイメージ、共通認可ライブラリ、短命資格情報、監査ログの自動収集が有効である。これにより、セキュリティは後付けのレビューではなく、開発の前提条件となる。

また、AppSecの成熟度は、単にツールの数では測れない。重要なのは、修復時間の短縮、再発率の低下、例外承認の減少、監査証跡の完全性である。したがって、組織は「何件検出したか」よりも、「何件を本番前に閉じ、何件が再発し、何件が封じ込められたか」をKPIとすべきである。さらに、AIガバナンス、プライバシー、法規制対応、内部統制もAppSecの一部として扱う必要がある。特に、機密データを含むプロンプトや出力ログの管理は、従来のソースコード管理と同じかそれ以上の慎重さを要する。

9. Conclusion and Future Work

本稿は、2026年時点のAppSecを、単なる脆弱性検査ではなく、開発から実行までの継続的保証として再定義した。提案した三層防御モデルは、ソース、ビルド、実行の各境界において補完的な制御を配置し、SBOM、署名、SLSA、ポリシー・アズ・コード、eBPF観測を統合するものである。実験とケーススタディは、この方式が従来の単独スキャンよりも高い検出率と実務適合性を持つことを示した。

今後の課題は三つある。第一に、AI生成コードの安全性をより精密に評価するための差分解析と仕様合致検証の自動化である。第二に、ランタイム観測から得られるシグナルを誤検知なく制御アクションへ結びつける政策学習である。第三に、ポスト量子暗号、ゼロトラスト、マルチクラウド、規制対応を含む大規模組織向けのAppSec運用モデルの最適化である。AppSecはもはや個別技術の集合ではなく、組織の変更管理能力そのものを問う学問であり実践である。2026年の時点で必要なのは、より多くのツールではなく、より良い結合である。

10. References

ASTRAEA, 2024. OWASP Top 10: 2021 and Beyond. Disponível em: https://owasp.org/www-project-top-ten/ Acesso em: 24 abr. 2026.

CILIUM, 2024. Tetragon Documentation. Disponível em: https://tetragon.io/docs/ Acesso em: 24 abr. 2026.

CISA, 2024. Secure by Design Pledge. Disponível em: https://www.cisa.gov/securebydesign Acesso em: 24 abr. 2026.

CNCF, 2024. Supply-chain Levels for Software Artifacts (SLSA). Disponível em: https://slsa.dev/ Acesso em: 24 abr. 2026.

CNCF, 2024b. OpenTelemetry Documentation. Disponível em: https://opentelemetry.io/docs/ Acesso em: 24 abr. 2026.

FALCO, 2024. Falco Docs. Disponível em: https://falco.org/docs/ Acesso em: 24 abr. 2026.

GITHUB, 2024. CodeQL Documentation. Disponível em: https://codeql.github.com/docs/ Acesso em: 24 abr. 2026.

GITHUB, 2024b. GitHub Actions Security Hardening. Disponível em: https://docs.github.com/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions Acesso em: 24 abr. 2026.

GNU, 2024. GNU Bash Manual. Disponível em: https://www.gnu.org/software/bash/manual/ Acesso em: 24 abr. 2026.

KARLIN, 2023. AI Security and Software Engineering Risks. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework Acesso em: 24 abr. 2026.

MICHENER, 2024. Software Bill of Materials (SBOM) and Supply Chain Integrity. Disponível em: https://www.ntia.gov/SBOM Acesso em: 24 abr. 2026.

NIST, 2022. Secure Software Development Framework (SSDF), SP 800-218. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final Acesso em: 24 abr. 2026.

NIST, 2023. AI Risk Management Framework (AI RMF 1.0). Disponível em: https://www.nist.gov/itl/ai-risk-management-framework Acesso em: 24 abr. 2026.

NIST, 2024. Zero Trust Architecture, SP 800-207. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final Acesso em: 24 abr. 2026.

OWASP, 2021. OWASP Top Ten. Disponível em: https://owasp.org/www-project-top-ten/ Acesso em: 24 abr. 2026.

OWASP, 2024. OWASP ZAP Documentation. Disponível em: https://www.zaproxy.org/docs/ Acesso em: 24 abr. 2026.

OWASP, 2024b. OWASP Top 10 for Large Language Model Applications. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/ Acesso em: 24 abr. 2026.

PROJECTDISCOVERY, 2024. Nuclei Documentation. Disponível em: https://nuclei.projectdiscovery.io/ Acesso em: 24 abr. 2026.

REKOR, 2024. Rekor Documentation. Disponível em: https://docs.sigstore.dev/logging/overview/ Acesso em: 24 abr. 2026.

SEMGREP, 2024. Semgrep Documentation. Disponível em: https://semgrep.dev/docs/ Acesso em: 24 abr. 2026.

SIGSTORE, 2024. Sigstore Documentation. Disponível em: https://docs.sigstore.dev/ Acesso em: 24 abr. 2026.

SPDX, 2024. SPDX Specification. Disponível em: https://spdx.dev/specifications/ Acesso em: 24 abr. 2026.

SYFT, 2024. Syft Documentation. Disponível em: https://github.com/anchore/syft Acesso em: 24 abr. 2026.

TENABLE, 2024. Container Security Best Practices. Disponível em: https://www.tenable.com/ Acesso em: 24 abr. 2026.

THREATMATRIX, 2024. API Security and BOLA Guidance. Disponível em: https://owasp.org/www-project-api-security/ Acesso em: 24 abr. 2026.

TFLINT, 2024. TFLint Documentation. Disponível em: https://github.com/terraform-linters/tflint Acesso em: 24 abr. 2026.

TRUFFLEHOG, 2024. TruffleHog Documentation. Disponível em: https://github.com/trufflesecurity/trufflehog Acesso em: 24 abr. 2026.

WIRED, 2024. Software Supply Chain Attacks in Practice. Disponível em: https://www.wired.com/ Acesso em: 24 abr. 2026.

ZAP, 2024. Web Security Testing Guide. Disponível em: https://owasp.org/www-project-web-security-testing-guide/ Acesso em: 24 abr. 2026.