Kush's Wiki

Sort by - linked count

• zizmor/

  template-injection
  #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
• zizmor/

  overprovisioned-secrets
  #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
• zizmor/

  excessive-permissions
  #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
• DNSラベル標準
  #Network RFC 1123で定義されているDNSに指定可能な文字列
• Agile testing directions: tests and examples
  #Testing Agile Testingにおけるアジャイルテストの4象限の源流となったブログ記事 http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2
• Kubernetesで実践する Platform Engineering
  
• テイルレイテンシ
  p95, p99, p999のような極端に悪い外れ値を考慮外にする大きなパーセンタイル値のこと 信頼性の計測において用いられる
• Sigstore
  #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/
• Istio/

  ingressgateway
  #Network Istioにおいて、Gatewayに対しデフォルトで追加されるトラフィックの入り口
• Istio/

  PeerAuthentication
  #Security/Authentication Istioにおいてマイクロサービス間のmTLSを設定するカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/peer_authentication/
• レポーティングデータベース
  #Data Engineering Martin Fowlerが示したパターンで、アプリケーションのドメインモデルに対応するテーブルとは別にレポート目的の中間テーブルを用意することで、レポートの関心を分離してテーブルに変更を加えることができる。 https://bliki-ja.github.io/ReportingDatabase
• Michael Nygard
  Home X 人物
• Dynamoスタイル
  #Data Engineering DynamoDBによって流行したリーダーレスレプリケーションを実装したデータストアに用いられるスタイル名
• NINES don’t matter if USERS aren’t HAPPY
  SREの文脈でのCharity Majorsによる主張。ナインとは可用性のこと ユーザーが満足していなければ、ナインは重要ではない
• 技術的負債の4象限
  Technical Debt Quadrant Martin Fowlerが技術的負債が発生するケースを4象限で分類したもの。 Reckless（無謀） or Prudent（慎重） Deliberate（意図的） or Inadvertent（不注意） の2軸で分類する。 例えばリリース当初はクリーンなコードを書いていたつもりだが、1年後に本来正しかった設計が見つかった。のようなケースではPrudentかつInadvertentとなる Blog ブログ
• USM/

  バックボーン
  #Agile #Product Management ユーザーストーリーマッピングの最上部に配置されるユーザーの主要なアクティビティの流れ アクティビティを時系列で左から右に並べ、プロダクト全体のユーザージャーニーを表現する 各アクティビティの下にユーザータスクをぶら下げ、さらにその下にストーリーを配置する
• ArchiMate
  #Documentation エンタープライズ・アーキテクチャーを記述するためのグラフィカルなオープンソース言語 https://www.archimatetool.com/
• 分散コンピューティングの8つの誤謬
  #Network 分散システムを扱い際、しばしば陥りがちなネットワークへの仮定を8つリストアップしたもの ネットワークは信頼性がある レイテンシはゼロ 帯域幅は無限 ネットワークは安全 トポロジは変わらない 管理者は1人だけ 転送コストはゼロ ネットワークは均質 https://nighthacks.com/jag/res/Fallacies.html
• ゴールレベル
  #Agile #Product Management Alistair Cockburnが提唱した、ゴール（目的）の大きさをレベル（高さ）で捉える考え方。高いレベルほど要約的で大きな目的を、低いレベルほど具体的な手順を表す。
• Peer DID
  #Security/Authentication #Security/Authorization DIDにおいて自己証明自律型識別子を提供する did:peer DIDメソッド定義 DIDドキュメント相当の情報をパブリックに公開しないため、安価でありセキュリティ強化に繋がる authorization セクションによる認可制御が可能 https://identity.foundation/peer-did-method-spec/
• MADR
  Markdown Architectural Decision Records #Documentation ADRを記述するテンプレートカテゴリの一つ。マークダウンによって構造化された文書を提供する bare / minimal / full の3バリアントを持ち（現行 4.0.0）、決定の重さに応じて使い分けられる。共通の核は Context and Problem Statement / Considered Options / Decision Outcome で、full はこれに Decision Drivers / Pros and Cons of the Options / Confirmation 等を加える https://github.com/adr/madr/tree/develop/template About MADR | MADR
• Helmfile
  Helmfileは、Helmチャートをデプロイするための宣言的な仕様を提供するツールです。宣言的な構成管理はInfrastructure as Codeの実践であり、GitOpsワークフローに適し、複数のHelmリリースを効率的に管理することができます。 概要 Helmfileを使用することで、Kubernetes環境における複数のHelmチャートのデプロイメントを、YAMLファイルで宣言的に管理できます。これにより、環境ごとの設定の違いを明確にし、再現性の高いデプロイメントを実現します。 主な機能 複数のHelmリリースを一つのファイルで管理 環境ごとの値のオーバーライド リリース間の依存関係の定義 デプロイの差分確認（diff機能） https://helmfile.readthedocs.io/en/latest/ DevOps
• Kanban and Scrum: Making the Most of Both
  かんばんとスクラム 両者のよさを最大限ひきだす #Agile カンバンとスクラムそれぞれのよさを最大限引き出す方法を解説したミニブック https://www.infoq.com/jp/minibooks/kanban-scrum-minibook/
• 契約による設計
  #Programming #Software Design オブジェクト指向プログラミングの文脈で提唱された、事前条件・事後条件・不変条件でクラスの振る舞いを規定する設計手法。 契約による設計事始め
• gh auth login
  #Security/Authentication GitHub CLI (gh) の認証コマンド。OAuth でブラウザ認証し、以降の API / Git 操作に使う長命の OAuth トークン（gho_…）をローカルに保存する 特徴 発行されるのはユーザー本人の権限・名義で動く長命トークン（明示失効するまで切れない） gh 2.24.0（2023-02）以降、保存先は OS の資格情報ストア（macOS Keychain / Windows Credential Manager / GNOME Keyring）がデフォルト。平文 ~/.config/gh/hosts.yml への保存は --insecure-storage での opt-in https://github.com/cli/cli/discussions/7109
• トランザクション分離レベル
  #Data Engineering ACIDのうち、I（Isolation）について言及するような分離性のレベル。 RDBMS間で共通して4つの分離レベルがあるが、分離レベルの命名が異なるケースがあり曖昧になっている。 Read Uncommitted コミットされていない未確定のデータを読み取るダーティリードが発生する Read Committed ダーティリード、ダーティライトが生じない Snapshot Isolation OracleではSERIALIZABLE、PostgreSQLやMySQLではRepeatable Readと呼ばれるため曖昧 読み取りスキュー（nonrepeatable read）が生じない、読み取りはロックを取らず常にトランザクション開始時のスナップショットを参照する スナップショットとして複数のバージョンを保持するためMVCC（multi-version concurrency controll）の手法が用いられる Serializable 書き込みスキュー（ファントム）が生じない、複数のレコードを跨いだ一貫性を保証する ユニーク制約によって書き込みスキューを防止できない際に必要となる 全てのトランザクションが直列で実行されるように振る舞うことで直列化可能と呼ばれる
• Claude Fable/

  5
  #LLM Anthropic社が2026年6月9日に一般提供を開始したClaudeの最上位モデル。最も要求の厳しい推論と長時間の agentic 作業向け コンテキストウインドウは1Mトークン（デフォルト）、出力は最大128kトークン 価格は$10 / $50 per Mトークン（input / output） adaptive thinking が常時オンで無効化できず、raw な思考過程は返さない https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5
• JWKS
  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)
• Manuel Pais
  
• DevOps capabilities/

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

  Test data management
  #Testing DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Test data management
• DevOps capabilities/

  Version control
  DevOps capabilitiesの1つ、Fast Flowに分類される アプリケーションコードだけでなく、ビルドスクリプトやコンフィギュレーションに対しても管理を行うことが推奨され、継続的インテグレーションに寄与する DORA | Capabilities: Version Control
• DevOps capabilities/

  Deployment automation
  #API Architecture DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Deployment Automation
• DevOps capabilities/

  Proactive failure notification
  #Observability DevOps capabilitiesの1つ、Fast Feedbackに分類される https://dora.dev/capabilities/proactive-failure-notification/
• DevOps capabilities/

  Streamlining change approval
  DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Streamlining change approval
• DevOps capabilities/

  Job satisfaction
  DevOps capabilitiesの1つ、Climate for Learningに分類される https://dora.dev/capabilities/job-satisfaction/
• DevOps capabilities/

  Transformational leadership
  DevOps capabilitiesの1つ、Climate for Learningに分類される DORA | Capabilities: Transformational leadership
• DevOps capabilities/

  Empowering teams to choose tools
  #Software Design DevOps capabilitiesの1つ、Climate for Learningに分類される 仕事の満足度に寄与し、ツールやテクノロジーをチームに強制するとチームによる実験が制限されてしまう DORA | Capabilities: Empowering teams to choose tools
• DevOps capabilities/

  Monitoring and observability
  #Observability DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Monitoring and observability
• DevOps capabilities/

  Visual management
  DevOps capabilitiesの1つ、Fast Flowに分類される WIP制限と組み合わせると良い DORA | Capabilities: Visual management
• MVS
  Minimum Viable Solution #Agile #Product Management 期待する成果を達成できる最小のリリース単位 MVPがProductという語で新規プロダクトを想起させるのに対し、Solutionに置き換えることで既存プロダクトへのリリースにも適用できるよう概念を広げている
• RAG
  Retrieval-Augmented Generation 検索拡張生成 #LLM プロンプトエンジニアリングにおいて、LLMが学習済みータだけではなく、外部データベースから関連情報を検索し、回答を生成する技術
• SoE
  System of Engagement 顧客との関係性を重視するシステム、ECサイト等が該当する
• ORM
  Object-Relational Mapping #Data Engineering オブジェクト指向プログラミングアプリケーションとリレーショナルデータベース間のレイヤを抽象化するプロセス
• pinact
  #Security #Continuous Integration GitHub Actions の action / reusable workflow の参照を full-length commit SHA に pin する CLI（@suzuki-shunsuke 製）。タグは可変で改ざんの余地があり、SHA 固定だけが不変なリリース参照になる、というサプライチェーン攻撃対策。 pinact run で参照を SHA に pin（# v3.5.1 のバージョンコメント付き）。--update で更新、整合の検証にも対応 --no-api で API なしの構文チェック、--min-age でリリース直後の参照を弾く https://github.com/suzuki-shunsuke/pinact
• Knative Serving
  Knativeにおいて、KubernetesのCRDによって4種類のリソースを定義しアプリケーションの提供を行う Serviceの別APIのようなサービスディスカバリパターン Scale to zeroや自動スケーリングによるリソース効率の最適化が主な目的 https://github.com/knative/specs/blob/main/specs/serving/overview.md
• 抽象化によるブランチ
  #Continuous Integration Martin Fowlerが示した、抽象化レイヤーを介して大規模な変更を段階的に行う手法 BranchByAbstraction
• Cloud Native Maturity Model
  CNMM #Cloud Nativeの成熟度に関して、各成熟度レベルをビジネスとテクノロジの双方で主要領域を定義するモデル モデルの取り組みは単なる技術的取り組みではなく以下の5つの主要領域の影響を受ける Business outcomes People Process Policy Technology FinOpsとも接続が強く、成熟初期はコストが増加するが成熟につれてコストを節約できる特徴について触れている。また、Platform Maturity Modelと連携しており、トップダウンとボトムアップの両方をカバーする 成熟度レベルは五段階で以下のようになっている Level 1 - Build Level 2 - Operate Level 3 - Scale Level 4 - Improve Level 5 - Adapt https://maturitymodel.cncf.io/
• SECIモデル
  知識を暗黙知と形式知に分けそれらが学習サイクルに表れる過程をモデル化したもの 以下の4つのフェーズを繰り返す 共同化（Socialization） 暗黙知から暗黙知。組織として共通の経験を積み重ねる 表出化（Externalization） 暗黙知から形式知。経験的知識の共通点や抽象的な構造をモデル化する 連結化（Combination） 形式知から形式知。複数の形式知から知識体系を作る 内面化（Internalization） 形式知から暗黙知。形式知を実践的に理解できた状態
• OWASP Cheat Sheet Series/

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