#Security #Testing #Continuous Integration #Programming コード品質とセキュリティを継続的に検査するオープンソースの静的解析プラットフォーム 35以上のプログラミング言語に対応し、バグ、脆弱性、セキュリティホットスポット、コードスメルを検出する 主な機能 Quality Gates - デプロイ可否を判断するカスタマイズ可能な品質基準 SAST機能 - 静的コード解析によるセキュリティ脆弱性の検出 AI CodeFix - AIによるコード品質・セキュリティ問題の自動修正提案 IDE統合 - リアルタイムフィードバックと修正提案 DevSecOpsのシフトレフトセキュリティを実現し、適応度関数のコード品質カテゴリに該当する https://www.sonarsource.com/products/sonarqube/

JSON Web Token #Security/Authentication トークン自体の情報（例: 期限）を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない JWTは.によって3つのセクションの文字列に分割できる（署名がない場合3つ目のセクションは空） それぞれのセクションの文字列は構造化されたJSONをBase64URLエンコードした結果となっている ヘッダー 1つ目のセクションはヘッダーとして以下のような構造を持つ { "typ": "JWT", "alg": "RSA256" } algで指定する署名アルゴリズムは3つ目の署名セクションの解読にて用いる ペイロード 2つ目のセクションはトークン自体のペイロードになる。ペイロードの中身はJSONであれば自由だが、JWTクレームと呼ばれる役割が明示・明示された項目群が存在する。 例として　iss（発行者）、sub（対象者）、exp（有効期限）などがある 署名 3つ目のセクションはHMACやRSAのような署名アルゴリズムを使った結果が保持される RFC 7519 - JSON Web Token (JWT)

#Programming #Security/Authentication Go用のOIDCライブラリ、golang.org/x/oauth2パッケージと統合される プロバイダーのDiscoveryエンドポイントから自動設定 IDトークン（JWT）の署名検証とクレーム抽出 リモートのJWKS取得とキャッシュ管理 https://github.com/coreos/go-oidc

Dynamic Application Security Testing #Security #Testing 稼働中のアプリケーションに対して外部から攻撃シミュレーションを行い、セキュリティ脆弱性を検出するテスト手法 ブラックボックステストとも呼ばれ、ソースコードを参照せず実行時の挙動を分析する 特徴 DevSecOpsの継続的セキュリティテストを実現 認証、セッション管理、入力検証などランタイムの脆弱性を検出 代表ツール: OWASP ZAP / Burp Suite 検出結果を SARIF 形式で出力するツールも多い https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing

#Security 脅威モデリングを行うためのツール群、Microsoftによって提供されている https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool

Open Cybersecurity Schema Framework #Security #Observability サイバーセキュリティイベントのログ記録とデータ正規化のためのオープン標準スキーマフレームワーク AWS、Splunk、IBMなどが2022年に設立、2024年11月にLinux Foundationへ参画 ベンダー非依存のスキーマで異なるセキュリティツール間のデータ統合を簡素化 カテゴリ、イベントクラス、データ型、属性辞書で構成 https://ocsf.io/

Multi Factor Authentication 多要素認証 #Security/Authentication

Role-based access control #Security/Authorization ロールごとに許可を定義する認可モデル これによりユーザーの部署異動等の際に即座に権限を変更できる

#Security ソフトウェアの依存・ビルド・配布といった信頼された経路を侵害し、正規の配布物を通じて下流の利用者へ到達する攻撃 標的に直接侵入せず「信頼の連鎖」を悪用する点が特徴で、上流を 1 つ侵害するだけで多数の下流へ伝播する 攻撃者は正規の配布物に紛れ込むため、利用者側の通常の検証では気づきにくい 防御は信頼の検証可能化が軸: 構成要素の固定（pinning）、最小権限、由来の署名検証、依存構成の可視化（SBOM）

#Security #Continuous Integration #Continuous Delivery DevOpsにセキュリティを統合したアプローチ ソフトウェア開発ライフサイクル（SDLC）の全段階にセキュリティを組み込む 主要な原則 シフトレフトセキュリティ 開発初期段階からセキュリティを考慮 自動化 CI/CDパイプラインへのセキュリティテストの統合 SAST / DAST の併用 コラボレーション 開発・セキュリティ・運用チームの協働 https://www.devsecops.org/

#Software Design #Cloud Native #Security/Authentication #Security/Authorization The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している。 追加された3つの新要因 2. API First - サービス設計において、実装前にAPIインターフェースを定義し契約駆動開発を促進 #API Architecture 14. Telemetry - メトリクス、ログ、トレースの収集を通じた包括的な監視機能 #Observability 15. Authentication and Authorization - 認証・認可をアプリケーション設計の第一級の関心事として組み込む Authentication / Authorization 既存要因の改訂 Kubernetes ConfigMap/Secretsなどコンテナ時代の設定管理や、Infrastructure as Code（IaC）による環境構築など、現代的なベストプラクティスを反映した注釈が追加されている。 https://www.vmware.com/docs/ebook-beyond-the-12-factor-app

#Cloud Native #Security #Continuous Integration Red Hatが提供するコンテナイメージレジストリサービス コンテナイメージの保存・配布を行い、SAST脆弱性スキャナーClairによる自動セキュリティスキャンを統合している 3つの提供形態がある Quay.io - Red Hatが運用するホスト型サービス。パブリックリポジトリは無料 Red Hat Quay - オンプレミスまたはプライベートクラウドにデプロイ可能。Operatorとしても提供 Project Quay - Apache 2.0ライセンスのOSS版 Docker Hubの代替として、エンタープライズ向けのアクセス制御やイメージ署名機能を備える https://quay.io/ https://www.projectquay.io/

Static Application Security Testing #Security #Testing ソースコード、バイトコード、バイナリを解析してセキュリティ脆弱性を検出するテスト手法 ホワイトボックステストとも呼ばれ、アプリケーションを実行せずにコードを分析する 特徴 DevSecOpsのシフトレフトを実現 #Continuous Integrationパイプラインに統合可能 SQLインジェクション、XSS、バッファオーバーフロー等を検出 https://owasp.org/www-project-devsecops-guideline/latest/02a-Static-Application-Security-Testing

Fitness Function #API Architecture システムの品質特性を数量化可能な指標で評価する、システムの目標を一貫して保証するためにビルドパイプラインに組み込まれる それぞれの特性は以下のようにカテゴライズされる コード品質（Code Quality） レジリエンス（Resiliency） オブザーバビリティ（#Observability） パフォーマンス（Performance） コンプライアンス（Compliance） セキュリティ（#Security） 運用操作性（Operability） Fitness function-driven development | Thoughtworks

数値ライブラリで始める安全なプログラミング #Programming #Security Scala Matsuri 2024での発表 ScalaのSpireライブラリを用いて安全な数値計算を行うテクニックを紹介している

#Security/Authentication DIDにおいてスキーム部の後に続き、名前空間として機能する。名前空間に対しDIDドキュメントというメソッド固有の仕様を解決できる 例として、イーサリアムブロックチェーンメソッドを使用するDIDは did:eth から始まる

#Security DoS攻撃の一種で、HTTPの不完全なリクエストを送り続けることでWebサーバーの接続を占有するApplication層攻撃。少ない帯域幅で単一マシンからサーバーをダウンさせることが可能で、スレッドベースのWebサーバー（Apache等）に対して特に有効 https://en.wikipedia.org/wiki/Slowloris_(cyber_attack)

#Security #Continuous Integration GitHub Actionsワークフローの静的解析を行うSASTツール。サプライチェーン攻撃や認証情報窃取につながる workflow 設定の不備を検出する Rust製。.github/workflows/ 配下の YAML を解析し、命名された audit ID 単位で検出 / ignore を行える 主な audit カテゴリ: dangerous-triggers template-injection unpinned-uses excessive-permissions overprovisioned-secrets https://zizmor.sh/ https://github.com/zizmorcore/zizmor

#Security/Authorization トークンを保持するBearer（持参人）が誰であれ、そのトークンをリソースへのアクセスに使うことができる 平文の文字列でシークレットや署名は扱わず、セキュリティはTLSのようなトランスポート層での仕組みに任せている HTTP通信のAuthorizationヘッダーに付与するのを推奨されている RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage

#Security/Authentication #Security/Authorization DIDにおいて自己証明自律型識別子を提供する did:peer DIDメソッド定義 DIDドキュメント相当の情報をパブリックに公開しないため、安価でありセキュリティ強化に繋がる authorization セクションによる認可制御が可能 https://identity.foundation/peer-did-method-spec/

Hash-based Message Authentication Code #Security/Cryptography 共通鍵とメッセージダイジェストによる共通鍵暗号方式 共通の鍵を有するので両者ともに署名付きトークンを生成・検証できる

#Security 機密性(Confidentiality) 完全性(Integrity) 可用性(Availability) の頭文字を取ったセキュリティの3つの柱

Secret Management System #Security Secretの保存とアクセスを行うAPIを提供する、Secretをユーザが扱う段階では常に暗号化された状態になる

#Security #Network クリックジャッキング攻撃を防ぐためのHTTPレスポンスヘッダー ページが<frame>、<iframe>、<embed>、<object>内で表示されることを制御する 設定値は以下の3つ DENY: すべてのフレーム表示を禁止 SAMEORIGIN: 同一オリジンのみフレーム表示を許可 ALLOW-FROM URI: 特定のURIからのフレーム表示を許可（非推奨） 現在はCSPのframe-ancestorsディレクティブの使用が推奨されている https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options

#Programming #Security/Authorization EffによるScala認可実装の話

#Security/Authentication 認証の実装指針をまとめたOWASP Cheat Sheet Series Session Management zxcvbn-ts Pwned Passwords TLS Client Authentication MFA OAuth2 OpenId SAML Brute Force https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

#Security/Authentication セッション管理の実装指針をまとめたOWASP Cheat Sheet Series HTTP Cookie https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

#Security DoS攻撃の防御戦略をまとめたOWASP Cheat Sheet Series OSIモデルに基づくCERT-EU分類を採用し、3つの攻撃層に分類している Application層：サーバリソースの枯渇またはアプリケーション機能の無効化（Slow HTTP攻撃など） Session/Protocol層：サーバやファイアウォール、ロードバランサーなどのリソース消費 Network/Volumetric層：ネットワーク帯域幅の飽和 主な防御戦略 単一障害点（SPOF）の排除と冗長性確保 グレースフルデグラデーション（部分的機能継続）の実装 入力検証（ファイルサイズ、リクエストサイズの上限設定） セッションタイムアウトの適切な設定 レートリミット（最小入信データレート、接続タイムアウト、帯域幅上限） ISPレベルでのIP偽装フィルタリング CPU集約的操作の回避 例外処理の適切な実装 静的リソースの別ドメイン配置 https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html

#Security release file / container image / binary / SBOM 等の software artifact を署名・検証し、ソフトウェアサプライチェーンの安全性向上を目的とする OSS プロジェクト 鍵ではなく OIDC identity（email / service account / CI workflow 等）に署名を紐付ける identity-based / keyless 方式が核。長命な署名鍵なしに 署名検証 を成立させ、サプライチェーン攻撃 の由来検証軸を担う 署名は ephemeral key 生成 → Fulcio（CA）が identity に紐付く短命証明書を発行 → 署名イベントを Rekor（append-only な透明性ログ）に記録し、検証はログ経由で行う OpenSSF（Linux Foundation）が主導 https://docs.sigstore.dev/about/overview/

主にDockerfileなどにおいて、非rootユーザーでのログインを推奨する#Securityベストプラクティス Dockerfile ベストプラクティス docker-node/docs/BestPractices.md at main · nodejs/docker-node

#Security/Authentication ingressgatewayに対して、JWTの検証を行うためのカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/request_authentication/

#Security/Authorization Istioにおいてアプリケーション（L7）認可の役割を担うリソース KubernetesのCRDによって用意されており、Network policyに比べ柔軟でHTTP特有の設定が可能 Istio / Authorization Policy

#Security/Authentication Istioにおいてマイクロサービス間のmTLSを設定するカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/peer_authentication/

#API Architecture #Security/Authorization RFC6749によって定義された認可フレームワーク 主に以下の定義を利用する リソースオーナー（Resource Owner） 保護されたリソースへのアクセス許可を行うエンドユーザー リソースサーバー（Resource Server） 保護されたリソースを所有するサーバー、アクセストークンを受け取り検証する クライアント（Client） リソースオーナーによる認可の委譲先、アクセストークンを使ってリソースサーバーへリクエスト可能 認可サーバー（Authorization Server） リソースオーナーの認証・アクセス許可時に認可グランドを返却したのち、クライアントにアクセストークンを発行する 初回アクセストークン利用までのプロトコルの流れは以下 Protocol Flow リソースオーナーによるアクセス許可時に認可サーバーが返す認可グランドは、認可コードが利用されることが多い RFC 6749 - The OAuth 2.0 Authorization Framework

Same Origin Policy #Security ホストドメインとポート番号が一致する場合にのみ、リソース間の相互交流を許可する

#Security zizmorの audit。${{ ... }} テンプレート展開で信頼できない入力（PR タイトル、issue body、commit message、外部 ref 等）を直接 shell コマンドや式に埋め込むパターンを検出する 検出例 - run: | title="${{ github.event.issue.title }}" なぜ危険か 上の ${{ github.event.issue.title }} は shell 評価前に文字列置換される — issue タイトルに "; rm -rf /; # のような文字列があるとそのまま shell コマンドとして実行される 攻撃者制御の文字列が直接 shell に混入し RCE dangerous-triggersと組み合わさると secrets が即座に外部送信できる 改善例 - run: | title="${ISSUE_TITLE}" env: ISSUE_TITLE: ${{ github.event.issue.title }} https://docs.zizmor.sh/audits/#template-injection

#Security zizmorの audit。pull_request_target や workflow_run のような書き込み権限と secrets を持ったまま走るトリガーの使用を検出する 検出例 on: pull_request_target なぜ危険か 上の pull_request_target は fork PR からのトリガーでもベースリポジトリの context で実行され、secrets と書き込み token がジョブに渡る fork PR の内容（タイトル、ref、checkout した head のコード）を信頼して扱うと、攻撃者がリポジトリの secrets 窃取やコミット改竄できる workflow_run も同種の高権限トリガー 改善例 on: pull_request https://docs.zizmor.sh/audits/#dangerous-triggers

#Security zizmorの audit。workflow / job レベルの permissions: が、その job が実際に必要とする以上の write 権限を持っているケースを検出する 検出例 permissions: id-token: write jobs: build: runs-on: ubuntu-latest publish: runs-on: ubuntu-latest steps: - uses: pypa/gh-action-pypi-publish@... なぜ危険か 上の例は workflow ルートで id-token: write を宣言しており、実際に必要なのは publish job のみ。build job にも同じ権限が継承される build 内で third-party action が侵害された場合（unpinned-uses）、本来不要な id-token: write も奪われる 被害は job が持つ GITHUB_TOKEN のスコープに比例する。最小権限の原則を CI トークンにも適用する 改善例 permissions: {} jobs: build: runs-on: ubuntu-latest publish: runs-on: ubuntu-latest permissions: id-token: write steps: - uses: pypa/gh-action-pypi-publish@... https://docs.zizmor.sh/audits/#excessive-permissions

#Security zizmorの audit。secrets context 全体を job に渡しているケース（toJSON(secrets) での注入や reusable workflow 呼び出し時の secrets: inherit など）を検出する 検出例 env: SECRETS: ${{ toJSON(secrets) }} なぜ危険か 上の toJSON(secrets) は secrets context 全体を 1 つの環境変数に注入する — 1 つの secret しか必要なくても全 secret が job プロセスから見える 同カテゴリの典型: reusable workflow 呼び出し時の secrets: inherit も全 secrets を子に流す 子側のコード変更や log への意図せぬ出力で、本来必要ない secret も漏洩面に入る 改善例 env: SECRET_ONE: ${{ secrets.SECRET_ONE }} SECRET_TWO: ${{ secrets.SECRET_TWO }} https://docs.zizmor.sh/audits/#overprovisioned-secrets

#Security zizmorの audit。uses: で third-party action を tag や branch 名（@v3、@main）で参照し、コミットSHAで pin していないケースを検出する 検出例 - uses: pypa/gh-action-pypi-publish@v1.12.4 - uses: docker://ubuntu なぜ危険か 上の @v1.12.4 (action tag) や docker://ubuntu (image tag 省略) は publisher 側で参照先を書き換え可能 — 過去に正当だったタグが後日マルウェア入りコミットを指すよう移動されると、CI を信用しているワークフロー全てが侵害される 近年の tj-actions/changed-files 事件はこのパターン: 同一 tag が遡及的に汚染されたコミットへ rebound された SHA は immutable なので、内容が変わらないことを暗号学的に保証できる 改善例 - uses: pypa/gh-action-pypi-publish@76f52bc884231f62b9a034ebfe128415bbaabdfc # v1.12.4 - uses: docker://ubuntu:24.04 https://docs.zizmor.sh/audits/#unpinned-uses

#Security Sigstore の CLI（client）。container image / blob / artifact の署名と 署名検証 を行う 署名のたびに ephemeral 鍵ペアを生成する keyless 方式に対応する（鍵を保管しない identity-based モデル） 自前鍵による key-based 署名もサポートする https://docs.sigstore.dev/cosign/signing/overview/

#Security/Cryptography メッセージの完全性を示す数学的手法、暗にハッシュと呼ばれることもある 不可逆 ハッシュ化された文書は元の文書に戻せない 非相関 元の文書の小さな変更が、ハッシュ化された文書では大きな変更となる 一意 同じメッセージダイジェストを生成する2つの文書は数学的に存在しない 最も一般的な使用法は、パスワードの安全な保存である

rootユーザーが持つ特権を細分化したもの Non-root Userへ必要最小限のケイパビリティを割り当てる方法は、Dockerの#Securityベストプラクティスとして紹介されている Docker のセキュリティ — Docker-docs-ja 1.12.RC2 ドキュメント

#Security/Authentication GitHub App の User Access Token をローカル開発向けに発行する CLI。Device Flow で認証し、8 時間で失効する短命トークンを払い出すことで、長命トークン（PAT や gh auth login の OAuth トークン）が漏洩した際のリスクを抑える 特徴 発行するのは User Access Token で、操作は App ではなくユーザー本人の権限・名義で行われる GitHub App の Client ID のみで動作し secret は不要。失効後は ghtkn get が Device Flow で自動再発行する トークンは OS の資格情報ストア（macOS Keychain / Windows Credential Manager / GNOME Keyring）に保存し、期限まで再利用する https://github.com/suzuki-shunsuke/ghtkn

#Security/Cryptography #Network TLSプロトコルにおいて、通信初期に公開鍵暗号方式によって通信を確立すること

#Security/Cryptography デジタル署名されたメッセージを受信者が検証すること。改竄されていないこと（完全性）と、送信者が送信を否認できないこと（否認防止）を確認できる

#Security 組織が当該ドメインを制御（domain validation）していることを認証局が証明するデジタル証明書

#Security SCA と SAST を軸にした AppSec / AI セキュリティの商用 SaaS プラットフォーム（旧 WhiteSource、SCA 市場の草分け） スキャン領域: SCA（到達可能な OSS 脆弱性検出・ライセンスコンプライアンス）/ SAST / コンテナイメージ / AI セキュリティ（AI コンポーネントの可視化・レッドチーミング・ランタイムガードレール） 特徴 reachability ベースの解析で到達可能な脆弱性に絞り込み、ノイズを減らす 修正 PR の自動生成（remediation-centric）で検出から修正までを支援する https://www.mend.io/

Threat Modeling #Security アプリケーションに影響を与える脅威、攻撃、脆弱性、対策を特定する技術 モデリング手法として5つのステップを繰り返すよう紹介している Defining security requirements. Creating an application diagram. Identifying threats. Mitigating threats. Validating that threats have been mitigated. https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

CA #Security/Authentication 信頼されたデジタル証明書の発行者

相互TLS認証 #Security/Cryptography #Network ネットワークの両端がTLS証明書を持ち相互に認証を行うことで、双方向で安全かつ信頼できることを保証する

#Security セキュリティ脆弱性をカテゴライズするような脅威モデリングでの方法論 Microsoft Threat Modeling ToolではSTRIDEを利用していくつかの自動分析を行うことができる STRIDEは以下の頭文字を取ったもの Spoofing（なりすまし） ブルートフォース攻撃 Tampering（改ざん） インジェクション攻撃 マスアサインメント攻撃 Repudiation（否認） ログ・監査証跡の不足 デジタル署名の欠如 タイムスタンプの不備 Information Disclosure（情報漏洩） 過剰なデータ露出 不適切なインベントリ管理 Denial of Service（サービス拒否） DoS攻撃 Elevation of privilege（権限昇格） https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool-threats#stride-model

PSS #Security Podが満たすべきセキュリティ標準 3つのセキュリティプロファイルにグループ分けされており上から順に制限が厳しくなっていく Privileged Baseline Restricted Pod Security Standards | Kubernetes Kubernetes

Pod定義に#Security文脈の設定を追加するAPI 主にLinuxベースの以下のような観点に対する制御を行う Non-root User Linux Capabilities Configure a Security Context for a Pod or Container | Kubernetes Kubernetes

PSA #Security Pod Security Standardsを違反する可能性がある際のアクションを実行する アクションは以下の3つ Warn Audit Enforce Pod Security Admission | Kubernetes Kubernetes

#Security Kubernetesクラスタとワークロードを保護するためのセキュリティ対策の総称 4Csセキュリティモデルに基づき、Cloud、Cluster、Container、Codeの各レイヤーで多層防御を実装する 主なセキュリティ機能: アクセス制御: ServiceAccount、Role、RBAC Pod保護: Security Context、Pod Security Standards、Pod Security Admission ネットワーク: Network policy、サービスメッシュ シークレット管理: Secret https://kubernetes.io/docs/concepts/security/

Identity Provider #Security/Authentication #Security/Authorization デジタルアイデンティティシステムにおいて、ユーザーの認証を行い、アイデンティティ情報を提供するサービスまたは組織 代表的なソーシャルIdPとして、Google、Facebook、GitHub、Microsoftなどがある OIDCやOAuth2プロトコルを用いてアイデンティティ情報を外部アプリケーションに提供する

#Security/Authentication ブルートフォース攻撃を防ぐための対策をまとめたOWASP Communityの記事 主な対策方法 アカウントロックアウト機能（DoS攻撃に悪用されるリスクに注意） Device Cookies（デバイスごとの認証ロック機構、DoS攻撃に対して耐性がある） パスワード検証時の遅延追加 IPアドレスベースのレートリミット CAPTCHAの導入 複数の秘密の質問による認証強化 単一の技術では回避されやすいため、複数の対策を組み合わせることが重要 https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

#Security #Network HTTP通信において、セッション管理にいくつかのセキュリティ機能を提供する

#Security OV証明書の内容に加えて、組織の情報と場所（extended validation）を認証局が証明するデジタル証明書

#Security Cookieの属性の1つ JavaScriptのようなスクリプトからのCookieアクセスを無効にする

#Security Cookie属性の1つ HTTPS通信を強制する

#Security Cookie属性の1つ 同一生成元ポリシーを許可するレベル Strict Lax None の3段階がある

Secure Sockets Layer #Network #Security/Cryptography TLSの前身 基本的にはdeprecatedだが、デジタル証明書発行等の文脈で引き続き用いられている https://www.cloudflare.com/learning/ssl/what-is-ssl/

#Network #Security/Cryptography 通信の初期段階に公開鍵暗号によって共通鍵暗号の鍵交換を行い、以降の通信を共通鍵暗号によって行う鍵システム 公開鍵暗号の計算コストの高さの課題から最小限の利用に留めている

#Security/Authorization 認可による保護対象

#Security/Authorization 主体とスコープとの紐付けをルールとして扱う

#Security/Authorization 保護対象のリソースに基づいて定める認可対象の機能範囲

Principal #Security/Authorization 認可チェックを受ける対象 ログインユーザーやAPIトークンなどがある

#Security #Cloud Native #Continuous Integration コンテナイメージ、Kubernetes、IaC、リポジトリを対象とした包括的な脆弱性・設定ミス・シークレットスキャナー Aqua Securityによって開発されたオープンソースツール 主な機能: 脆弱性スキャン - コンテナイメージ、ファイルシステム、gitリポジトリ IaC設定ミス検出 - Dockerfile、Kubernetesマニフェスト、Terraformなど シークレット検出 - APIキー、パスワード等の機密情報 SBOM生成 - ソフトウェア部品表の作成と検出 ライセンススキャン DevSecOpsのシフトレフトセキュリティを実現し、CI/#Continuous Deliveryパイプラインに統合可能 SASTツールの一種として静的解析を実行する。--format sarif で SARIF 出力に対応し GitHub Code Scanning に取り込める https://trivy.dev/ https://github.com/aquasecurity/trivy

#Security/Authentication #Security/Authorization ゴールドスタンダード（Gold Standard）は、セキュアなシステム設計における基本原則で、C-I-Aを保護する執行メカニズムとして機能します。 認証（Authentication）: ユーザーが本人であることを証明 認可（Authorization）: 認証されたユーザーの行動の許可・拒否を決定 監査（Auditing）: システムアクティビティの信頼できるログを維持 ラテン語で金を意味する「Aurum」の化学記号「Au」に由来し、3つの原則が「Au」で始まることからこの名称が付けられています。 https://designingsecuresoftware.com/text/ch1-gold/

Availability #Security データを利用可能な状態に保つこと。大幅な遅延や不正なシャットダウンを許さない

#Security #Network Cloud SQLへの接続を仲介するローカルプロキシ TLSによって接続を暗号化する IAMベースの認可で接続元を制御し、authorized networksやSSL証明書の管理を不要にする アプリケーションはローカルソケット（TCP/Unix domain socket）経由でプロキシに接続し、プロキシがCloud SQLインスタンスへトンネリングする https://cloud.google.com/sql/docs/mysql/sql-proxy https://github.com/GoogleCloudPlatform/cloud-sql-proxy

#Security Google Cloudが提供するSMS Secrets Store CSI Driverを用いてGKEに組み込み可能 Secret Manager の概要 | Secret Manager Documentation | Google Cloud

#Security Google Cloudにおいて外部ロードバランシングで必要となるようなTLS証明書を管理する Certificate Manager の概要 | Google Cloud

#Network #Cloud Native #Observability #Security https://cilium.io/ eBPF技術を活用したクラウドネイティブなネットワーキングソフトウェア KubernetesのCNIとしてネットワークの接続、保護、監視を提供する ユースケースとして以下のような例がある L4 ロードバランシング https://cilium.io/use-cases/load-balancer/ kube-proxy https://cilium.io/use-cases/kube-proxy/ サービスメッシュ https://cilium.io/use-cases/service-mesh/ Gateway API https://cilium.io/use-cases/gateway-api/ Ingress https://cilium.io/use-cases/ingress/

JSON Web Key Set #Security/Authentication #Security/Cryptography JWTの署名検証に用いる公開鍵群をJSON形式で表現する仕様（RFC 7517）。各キーはkid（Key ID）・kty（鍵種別）・alg（署名アルゴリズム）などのフィールドを持ち、配列としてまとめられる JWT認証プロバイダーは/.well-known/jwks.jsonのようなエンドポイントで公開し、リライングパーティはJWTヘッダーのkidで該当キーを選択して署名を検証する。鍵ローテーションは新旧キーの並存で実現する RFC 7517 - JSON Web Key (JWK)

Key Management Service #Security AWSが提供するKMS AWS Key Management Service

#Security DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Pervasive security

#Security/Authentication 簡単かつ安価にDV証明書を発行する認証局 https://letsencrypt.org/ja/

Security Assertion Markup Language #Security/Authentication XMLベースの認証・認可データ交換標準規格。IdPとSP（Service Provider）間で認証情報をやり取りし、SSO（Single Sign-On）を実現する。 https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

#Security HTTPS利用サーバーに対してHTTPリクエストを行う、または暗号アルゴリズムを脆弱なもので指定することで攻撃を行う

#Security/Authentication GitHub の機能を拡張するために作る integration の一種。アカウントにインストールして使い、付与した権限の範囲で動く。ユーザー本人に紐づく PAT と異なり、独立した主体として振る舞う サードパーティツールを GitHub と連携させる際の install 先として使うのが典型。App の ID と private key で認証し、短命のインストールアクセストークンを払い出すこともできる。 https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps

#Security/Cryptography HTTPレスポンスヘッダの一つ、Webサイトが常にHTTPSを使用していることをWebブラウザに認識させる

#Security メッセージが送信または受信を攻撃者が否認した際に、否認できないように保証すること

#Security #API Architecture 以下のような目的でAPIの使用回数を制限する、制限を超過した時はHTTPの場合一般に429エラーを返す処理 STRIDEにあるようなDenial of Service（サービス拒否）からアプリケーションを保護する カスケード障害の可能性を制限する リソースの使用量を測定し従量課金に利用できる レートリミットの実装アルゴリズムには以下のようなものがある 固定ウインドウ（Fixed window） 固定期間内の制限 スライディングウインドウ（Sliding window） 直近の期間内の制限 トークンバケット方式（Token bucket） 総リクエスト数（トークンのバケツ）を定義しリクエストごとにトークンが利用される。バケツは定期的に充填される リーキーバケット方式（Leaky bucket） リクエストが処理される速度は固定で、バケツから溢れ出るリクエストを漏れ（リーキー）として扱う APIゲートウェイを利用している場合、ゲートウェイに配置するとよい

Static Analysis Results Interchange Format #Security SAST / DAST ツールが検出結果を出力するための JSON ベース標準フォーマット。OASIS が策定し、現在は v2.1.0 が広く利用される GitHub Code Scanning の取り込みフォーマットとして採用されており、対応ツールの出力を Security タブの code scanning alerts に集約できる スキーマの主要要素 runs[] - 1 回のツール実行に対応 runs[].tool.driver - 解析ツール情報（name / version / rules） runs[].results[] - 個々の検出結果（ruleId / level / message / locations） physicalLocation - ファイル / 行 / 列の指定 https://sarifweb.azurewebsites.net/

#Security #Continuous Integration Gitleaks の開発元が手がける、シークレット（API キー・トークン・認証情報）を検出するスキャナー。GitHub/GitLab などの Git リポジトリ（Organization 単位も可）、S3、ローカルディレクトリなど複数のソースに対応する DevSecOps のシフトレフトとして CI に組み込み、コードや成果物へのシークレット混入を検出する https://github.com/betterleaks/betterleaks

Key Management System #Security/Cryptography 暗号化キーのディスカバリ、保存を行う管理システム。暗号化はKMS外で行う前提

Completely Automated Public Turing test to tell Computers and Humans Apart #Security/Authentication 人間とボット（自動プログラム）を区別するための技術 主な目的はブルートフォース攻撃の防止、スパムやボットによる自動投稿の防止、不正なアカウント作成の防止 代表的な実装として、Google reCAPTCHA、hCaptcha、テキストベースCAPTCHAなどがある アクセシビリティの観点から、音声CAPTCHAなどの代替手段の提供が推奨される https://www.cloudflare.com/ja-jp/learning/bots/how-captchas-work/

HyperText Transfer Protocol Secure #Network #Security/Cryptography HTTPをTLSによって暗号化した通信

#Security #Programming Go言語のソースコード静的セキュリティ分析ツール Go AST（抽象構文木）を解析し、セキュリティ問題となりうるプログラミングミスを検出するSASTツール 主な特徴: -includeまたは-excludeフラグで検査ルールを選択可能 検出された問題はCWE（Common Weakness Enumeration）にマッピングされる AI統合によるセキュリティ修正提案（Gemini、Claudeに対応） GitHub Actionとしても利用可能 インストール: go install github.com/securego/gosec/v2/cmd/gosec@latest https://github.com/securego/gosec

#Security Renovate の設定オプション。パッケージのリリースが公開されてから指定期間（例: "3 days" / "1 week"）経過するまで、そのバージョンへの更新 PR を作らず待機させる（旧名 stabilityDays） security 文脈 公開直後の悪意あるバージョンを取り込むのを避けるサプライチェーン攻撃の緩和策。コミュニティが侵害パッケージを検知・撤回するまでの猶予を置いてから更新する automerge と併用すると、自動マージ前のクールダウン期間として機能する 設定例 renovate.json で全更新に 3 日のクールダウンを課す。 { "minimumReleaseAge": "3 days" } https://docs.renovatebot.com/configuration-options/#minimumreleaseage

#Security/Authentication 既知のデータ侵害で利用されたパスワードかどうかを検証できるサービス、API https://haveibeenpwned.com/Passwords

#Security npmパッケージ@bitwarden/cli@2026.4.0がマルウェア混入により侵害されたサプライチェーン攻撃事例 多段ペイロード構成 Stage1: bw_setup.jsがBunランタイムをDL Stage2: 難読化された9.7MBのbw1.jsが認証情報を窃取 Stage3-4: audit[.]checkmarx.cxへ暗号化送信、GitHubへフォールバック 発火点: npm install時のpreinstallフック、およびbwコマンド実行時 窃取対象: SSH鍵 / GitHub PAT / npmトークン / クラウド資格情報 / ~/.claude.json等のAI設定 / .env 対策: 2026.4.1へ更新、資格情報ローテーション、npm ci --ignore-scripts、min-release-ageの設定 https://blog.flatt.tech/entry/bitwarden_compromise ブログ

#Security/Authentication 一定回数の不正なパスワード入力後にアカウントを一時的または永続的にロックするブルートフォース攻撃対策 主な問題点 DoS攻撃の標的になりやすい（攻撃者が大量のアカウントをロック可能） ユーザー名の列挙が可能（存在するアカウントのみがロックされる） ヘルプデスクへの負担増加 低速攻撃や複数ユーザー対象の攻撃に無効

#Team Organization #Security/Authentication #Security/Authorization Team Topologiesにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する

#Security Claude Code on the webに統合されたAI脆弱性スキャン機能。SASTのようなパターンマッチングではなくコードベース全体を推論し、ビジネスロジックの欠陥やアクセス制御の不備を検出する。多段階検証で偽陽性を除外し修正パッチを提案するが適用には人間の承認が必要 https://www.anthropic.com/news/claude-code-security

Personal Access Token #Security/Authentication GitHub のユーザー本人として API / Git 認証に使う個人向けアクセストークン。パスワードの代わりとなる認証情報で、HTTPS での Git 操作や gh CLI、外部サービスからの GitHub 連携に用いる 特徴 classic と fine-grained の 2 種類があり、fine-grained はリポジトリ単位・権限単位でスコープと有効期限を絞れる ユーザー権限を継承する長命トークンになりやすく、最小権限と短い有効期限の設定が推奨される https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

Attiribute-based access control #Security/Authorization 従来のRBACに対し、リソースに割り当てられた属性（AWSではタグ）に基づいて許可を定義する認可モデル リクエスト元であるプリンシパルの属性がリソースの属性と一致した場合に操作を許可するポリシーを設計する ABAC 認証で属性に基づいてアクセス許可を定義する - AWS Identity and Access Management

#Security/Authentication HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う

#Security changed-files action (≤ v45.0.7) が侵害されたサプライチェーン攻撃の脆弱性。全タグが malicious commit に retroactively 付け替えられ、汚染された action が GitHub Actions runner の secrets を workflow ログへ dump した (embedded malicious code)。 CWE-506 (Embedded Malicious Code) CVSS 3.1: 8.6 HIGH (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) 影響: tj-actions/changed-files ≤ v45.0.7、v46 で解消 https://www.cve.org/CVERecord?id=CVE-2025-30066 https://nvd.nist.gov/vuln/detail/CVE-2025-30066

Denial of Service #Security リソース（サイト、アプリケーション、サーバー）を本来の目的で利用不可にすることを目的とした攻撃。C-I-Aの可用性を侵害する ネットワークパケット操作、プログラム脆弱性の悪用、リソース枯渇など多様な手段で実行される 主な攻撃手法 メモリ枯渇（ユーザー指定オブジェクト割り当て、セッションデータ過剰蓄積） CPU負荷増加（ループカウンター制御、バッファオーバーフロー） リソース解放失敗（ファイルロック、DB接続の未解放） アカウントロックアウト機構の悪用 ネットワーク帯域幅の飽和 対策としてレートリミット、入力検証、冗長性確保、グレースフルデグラデーションなどがある

System for Cross-domain Identity Management #Security/Authentication ユーザーアイデンティティ情報を異なるシステム間で自動的にプロビジョニング・管理するための標準プロトコル 主な機能は以下の通り ユーザープロビジョニング（新規アカウント作成） デプロビジョニング（アカウント削除） 属性同期（ユーザー情報の更新） グループ管理 RESTful APIベースで、IdPとSP（Service Provider）間のユーザー情報同期を効率化する https://scimcloud.com/ https://datatracker.ietf.org/doc/html/rfc7644

#Security/Cryptography 公開鍵と秘密鍵の鍵ペアによって実現する暗号方式。 以下の2パターンによって暗号化、復号が行われる 送信者：公開鍵でメッセージを暗号化、受信者：秘密鍵で復号 可逆的：機密性、完全性、否認防止 送信者：秘密鍵でメッセージを暗号化、受信者：公開鍵で復号 デジタル署名/署名検証 不可逆的：完全性、否認防止

#Security Kim Cameronが提唱したデジタルアイデンティティシステムの設計原則 アイデンティティメタシステムが満たすべき7つの法則： User Control and Consent（ユーザー制御と同意）: ユーザーがアイデンティティ情報の開示を制御できる Minimal Disclosure for a Constrained Use（最小限の開示）: 特定の目的に必要な最小限の情報のみを開示 Justifiable Parties（正当な当事者）: アイデンティティ情報は正当な目的を持つ当事者にのみ開示 Directed Identity（指向性アイデンティティ）: ユニバーサル識別子と方向性識別子の両方をサポート Pluralism of Operators and Technologies（多元性）: 複数のアイデンティティ技術とプロバイダーの共存 Human Integration（人間との統合）: ユーザーが理解し判断できるシステム設計 Consistent Experience Across Contexts（一貫した体験）: コンテキスト間で一貫したユーザー体験を提供 https://www.identityblog.com/?p=352

Transport Layer Security #Network #Security/Cryptography 通信暗号化プロトコル ネットワーク通信開始時にTLSハンドシェイクによる通信の確立後、鍵交換を行いセキュアな通信を行う（ハイブリッド鍵システム） https://developer.mozilla.org/en-US/docs/Glossary/TLS

#Security pnpm v11.0.0 リリース。サプライチェーン攻撃 対策が大幅に強化された major update サプライチェーン緩和 minimumReleaseAge デフォルト 1 日（1440 分）— 新着 24h 以内のパッケージを resolve しない blockExoticSubdeps デフォルト true — exotic な subdep をブロック strictDepBuilds デフォルト true、allowBuilds で install scripts を明示的に allowlist 管理 pnpm sbom を新コマンドとして追加（SBOM 生成） その他の breaking changes Node.js 22+ 必須、pnpm 本体が pure ESM 化 .npmrc は auth/registry のみ。他設定は pnpm-workspace.yaml / 新 config.yaml へ移管 グローバルパッケージはパッケージごとに隔離ディレクトリで管理 https://github.com/pnpm/pnpm/releases/tag/v11.0.0

#Security/Authentication TypeScriptで書かれた、パスワード強度を検証するライブラリ https://github.com/zxcvbn-ts/zxcvbn

#Security/Authentication 公開鍵と名前や住所等の識別情報を組み合わせることで、鍵の所有者を識別し正しい鍵であることを保証する証明書 認証局にデジタル署名をさせて発行される

#API Architecture #Network #Security/Authentication #Security/Authorization 外部トラフィックに対してリバースプロキシ・ロードバランシングが持つようなネットワークのルーティング・セキュリティと可用性の向上に加え、以下のような機能横断的な要件を扱う役割 認証 認可 レートリミット リトライ サーキットブレーカー etc.

#Security "Unified Security Platform" を標榜する商用 SaaS（カテゴリは ASPM / Application Security Posture Management）。10 種類超のセキュリティスキャンを単一 UI に集約する スキャン対象: SAST / SCA / DAST / シークレット / IaC / コンテナ / CSPM / マルウェア / Code Quality / Outdated Software Terraform / CloudFormation / Kubernetes マニフェストの設定ミス検出にも対応 特徴 AutoFix / Bulk Fix で修正 PR を自動生成 AI Pentesting Agents による DAST 自動化（200+ エージェント） Aikido Intel - 依存パッケージのマルウェア検出 TL;DR Summary で脆弱性の要約と対応指針を提示 https://www.aikido.dev/

#Security npm / pip など各種パッケージマネージャの download をローカルプロキシで intercept し、マルウェアを含むパッケージのインストールを未然にブロックする OSS 対応 PM: npm, npx, yarn, pnpm, pnpx, rush, rushx, bun, bunx, pip, pip3, uv, poetry, uvx, pipx, pdm 特徴 リアルタイムスキャンに Aikido Intel (Open Source Threat Intelligence) を利用 公開から 48 時間未満のパッケージをデフォルトでブロック（サプライチェーン攻撃 緩和） Tokenless / no build data shared — credentials も telemetry も不要 Bash / Zsh / Fish / PowerShell の shell integration、CI/CD 用 shim、private registry 対応 https://github.com/AikidoSec/safe-chain

Rivest-Shamir-Adleman #Security/Cryptography 公開鍵暗号方式のアルゴリズムの一種 現実的に解読できない素因数分解によって高い信頼性を持つ RFC 8017 - PKCS #1: RSA Cryptography Specifications Version

#Security GitHub Actionsの人気 action changed-files が侵害されたサプライチェーン攻撃事例 CVE-2025-30066 発覚: 2025-03-14 09:00 PT (16:00 UTC)、StepSecurity が Harden-Runner の挙動監視で検知 侵害手法: @tj-actions-bot の PAT が奪取（取得経路は不明） リポジトリ外で作成した malicious commit (0e58ed86...) に全タグを retroactively 付け替え（tag 移動による action 汚染の典型） ペイロード: Python script が /proc/[pid]/mem 経由で GitHub Actions runner プロセスのメモリから secrets を dump、log に double base64 で出力 影響: 23,000+ リポジトリ。compromise 窓は約 37 時間 (2025-03-14 16:00 UTC 〜 2025-03-15 22:00 UTC)。public repo の log は誰でも読めるため secrets 漏洩 復旧: 2025-03-15 22:00 UTC に GitHub がリポジトリを復旧、その後 v46.0.1 リリース 対処: step-security/changed-files@v45 等への切替、または SHA pin 化、漏洩可能性ある secrets を rotate https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised ブログ

#Security/Cryptography 暗号方式において、全世界に公開される前提の鍵を指す

Confidentiality #Security プライベートな情報を許可された方法のみで開示すること

#Security/Cryptography メッセージ送信者によるデジタル署名と、受信者による署名検証によって メッセージの改竄がされていないこと（完全性） メッセージが本当に秘密鍵を保持する送信者からのものであること（否認防止） の2つを保証する

#Network #Observability #Security #API Architecture マイクロサービスで行われるようなサービス間通信をルーティング、監視、保護する機能を提供する Kubernetesにおいてはクラスタ単位でサービスメッシュを構築する サービスメッシュはクラスタ内の全てのサービス間通信を制御するコントロールプレーンとコントロールプレーンで指定された作業が実行されるデータプレーン（サービス）の2つの基本要素を持つ。

#Security OWASP Foundationが発表するセキュリティ専門家によるトップ10に含まれるべき脆弱性リスト 定期的に更新されるため最新を追うべき https://owasp.org/www-project-top-ten/

分散型識別子 #Security/Authentication 暗号識別子の一種である。W3Cの分散型識別子ワーキンググループによってDID仕様が定義される 以下のような特性を持つ 再割り当て不可 解決可能 DIDメソッドを元にしたDIDドキュメントの取得 所有権の証明 デジタル署名 非集中型 URIとして表現され、以下例のような構文になる did:example:123456789abcdefghij did スキーム部、 did で固定 example メソッド部 123456789abcdefghij メソッド固有識別子部 https://www.w3.org/TR/did-1.0/

#Security/Cryptography メッセージの暗号化と複合に同じ鍵を使う暗号方式

#Security/Authentication ブルートフォース攻撃を軽減するための認証ロック機構。ユーザーが正常に認証された後、そのブラウザに発行される特別なCookie 従来のアカウントロックアウトと比較して以下の利点がある DoS攻撃に対して耐性がある IPアドレスではなくブラウザCookieを基準とするため予測可能で実装しやすい ボットネットや代理経由の攻撃に対応しやすい 認証リクエスト時に有効なDevice Cookieの有無を確認し、未信頼クライアント（Device Cookieなし）からの認証試行回数を記録してロックアウトを実施する 実装にはJWT、Redis/Memcachedによるロックリスト管理、HMAC署名による改ざん防止などが用いられる https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies

#Security GitOpsの世界においてSecretをクライアントサイドで扱うGo製のツール。YAMLやJSONのファイル上でSecretを安全にgit管理することができる ageを用いたローカルでのキー管理か、KMSによるキー管理のどちらを選択できる CNCF sandbox project https://getsops.io/

#Network #Security/Cryptography TLSによるHTTPS通信において、TLSハンドシェイクに用いるデジタル証明書のこと

#Security/Authentication 総当たり攻撃。パスワードや暗号鍵などを、可能な組み合わせを全て試すことで解読を試みる攻撃手法 対策として以下のような方法がある 強力なパスワードポリシーの適用（zxcvbn-ts、Pwned Passwordsによる検証） アカウントロックアウト機能 レートリミットによるログイン試行回数の制限 MFAの導入 CAPTCHAの利用 https://www.ipa.go.jp/security/vuln/websecurity/brute-force.html

#Security 2002年にAndre Durandが提唱した「Three Tiers of Identity」というフレームワーク。デジタルアイデンティティを3つの階層に分類する。 T1 - Personal Identity（個人アイデンティティ）: 時間を超えて不変で無条件。真の個人的デジタルアイデンティティであり、完全に本人が所有・管理し、本人の利益のためだけに存在する。 T2 - Corporate Identity（共有アイデンティティ）: 条件付きで一時的に割り当てられる。本人または発行した企業のいずれかによって取り消し可能。通常、ビジネス関係のコンテキストで本人を指す。 T3 - Marketing Identity（抽象化されたアイデンティティ）: 通常、人口統計やビジネスとのやり取りにおける行動に基づく。

Principle of Least Privilege #Security ユーザーやプロセスに対して、その役割を遂行するために必要な最小限の権限のみを付与する原則 不要な権限を排除することで攻撃面を削減し、セキュリティ侵害時の影響範囲を制限する

#Security/Authentication DIDにおいて、識別された主体と対話を開始するために必要な公開鍵、認証プロトコル、サービスエンドポイントが記述されている

#Programming #Security Scala言語の数値型ライブラリ。汎用的で高速かつ高精度な数値と、効率的な数値コードシンタックスを提供する。 Spire Introduction to Spire Numeric Programming in Scala with Spire JOTB19 - Numeric Programming with Spire by Lars Hupel

#Security OWASP Incubating Project の開発者向け統合セキュリティプラットフォーム。AGPL-3.0、Go + PostgreSQL 実装 シークレットスキャン / SAST / SCA / IaC / コンテナスキャン / ライセンスチェックを単一 CLI に統合し、サプライチェーン攻撃 対策まで含めて開発ワークフローに組み込む 主な機能 標準準拠スキャナ（Trivy / Grype / Semgrep）の出力を取り込み CVSS + EPSS + component depth に基づくリスク優先順位付け SBOM / VEX のライブ管理、依存パッケージの Dependency Firewall（npm / Go / Python） OPA/Rego によるポリシー強制、GitHub / GitLab / Jira との双方向同期 オープン標準（SBOM / VEX / SARIF / SLSA / in-toto）を中核に据える https://devguard.org/ https://github.com/l3montree-dev/devguard

#Security miseのEnvironment機能における機密情報管理について、mise開発元のfnoxまたはsops, ageを用いて解決する方法 https://mise.jdx.dev/environments/secrets/

#Security mise の設定。tool のリリースが公開されてから指定期間が経つまで、その新バージョンを install 対象から除外する 値は相対指定（7d / 90d / 6m / 1y）または絶対日付（2024-06-01 等） 公開直後の侵害バージョンの取り込みを避け、コミュニティが検知・撤回する猶予を置く サプライチェーン攻撃 の timing 緩和策 https://mise.jdx.dev/configuration/settings.html#minimum_release_age

#Security 組織が法的に登録されたビジネスである（organization validation）ことを認証局が証明するデジタル証明書

#Security/Cryptography シンプルでモダンな暗号化ツール、Go製 https://github.com/FiloSottile/age

#Security OWASPが公開する、開発チーム内に「セキュリティ・チャンピオン」を育成・運営するためのガイドブックプロジェクト ベンダーニュートラルなプレイブックとして、プログラム憲章・KPI・教育コンテンツ等のカスタマイズ可能なアーティファクトを提供する 成功のための10原則: Be passionate about security Start with a clear vision for your program Secure management support Nominate a dedicated captain Trust your champions Create a community Promote knowledge sharing Reward responsibility Invest in your champions Anticipate personnel changes https://securitychampions.owasp.org/

oauth-proxy #Security #Cloud Native #Network OAuth2/OIDC認証を提供するリバースプロキシ 主な特徴: Google、Azure、GitHub等の複数のIDプロバイダーに対応 Kubernetesクラスタ内のアプリケーション保護に利用可能 メール、ドメイン、グループ単位での認証制御 CNCF Sandboxプロジェクト distrolessベースイメージで高セキュリティ https://github.com/oauth2-proxy/oauth2-proxy https://oauth2-proxy.github.io/oauth2-proxy/

Insecure Direct Object Reference #Security/Authorization アクセス制御の不備により、URLやパラメータのID等を変更するだけで他のユーザーのデータにアクセスできてしまう脆弱性 OWASP Top Tenにおける代表的な脆弱性の一つで、Broken Access Controlの典型例 主な攻撃パターン URL操作: /user/123を/user/124に変更して他ユーザーの情報にアクセス リクエストボディ操作: POSTやPUTリクエストのID部分を改ざん ファイルアクセス: 静的ファイルのパス操作による機密情報の取得 対策として認可チェックの実装とUUIDのような推測困難なIDの利用が重要 https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

Integrity #Security データを正確に管理する、不正な変更や削除を許さない

Secure Hash Algorithms #Security/Cryptography デジタル署名の改竄防止等で最もよく利用されているハッシュ化アルゴリズム。生成される固定長のハッシュ値はメッセージダイジェストと呼ばれる 異なる元データから同一のハッシュ値が生成される可能性が低いことを求められ、SHA-2, SHA-256 等の種類がある RFC 6234 - US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)