Kush's Wiki

Sort by - linked count

• anyhow
  #Programming Rustにおけるエラー型の扱いを楽にするライブラリ パブリックなAPIでは利用を避けて標準のエラー型を用いるのが良い anyhow - Rust
• ent
  #Programming Go言語のORMライブラリ Facebook社で開発されたのち、Linux Foundationに参画し現在はAriga社で開発が継続されている https://github.com/ent/ent
• Trivy
  #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
• Principal Engineering Community Tenets
  Amazonのプリンシパルエンジニアグループによるコミュニティの信条 https://www.amazon.jobs/content/en/teams/principal-engineering/tenets
• 輻輳制御
  #Network TCPプロトコル等で行われるネットワークのリンク上でパケットが混線した際の制御 輻輳制御アルゴリズムは大きく以下の3つに分類される Loss-based Delay-based ハイブリッド型
• Device Cookies
  #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
• チェーホフの銃の誤謬
  有用なコンテキストが埋もれないように不要な要素は削除すること 「第一幕で壁に銃銃掛けるのであれば、次の幕でそれを撃たなければならない。もしそうでないのなら、最初からそこに掛けるべきではない」 と劇作家のアントン・チェーホフによって述べられている
• サービスの信頼性の階層
  
• Devin Wiki
  #Documentation #LLM Devinと連携されたリポジトリの内容を説明するWikiを生成する機能 自動でインデックスされる
• 広木 大地
  
• スクラム/

  経験主義の三本柱
  スクラムが経験主義をベースにスクラムガイドで紹介している三本柱 透明性 検査 適応
• スクラム/

  5つの価値基準
  スクラムのスクラムガイドで紹介されている5つの価値基準 確約(Commitment) 集中(Focus) 公開(Openness) 尊敬(Respect) 勇気(Courage)
• スクラム/

  インクリメント
  #Agile スクラムの成果物として、動作するプロダクトのこと
• アイデンティティの階層
  #Security 2002年にAndre Durandが提唱した「Three Tiers of Identity」というフレームワーク。デジタルアイデンティティを3つの階層に分類する。 T1 - Personal Identity（個人アイデンティティ）: 時間を超えて不変で無条件。真の個人的デジタルアイデンティティであり、完全に本人が所有・管理し、本人の利益のためだけに存在する。 T2 - Corporate Identity（共有アイデンティティ）: 条件付きで一時的に割り当てられる。本人または発行した企業のいずれかによって取り消し可能。通常、ビジネス関係のコンテキストで本人を指す。 T3 - Marketing Identity（抽象化されたアイデンティティ）: 通常、人口統計やビジネスとのやり取りにおける行動に基づく。
• Property-Based Testing
  #Testingにおいて、Known unknownsをKnown knownsにできるよう、プロパティとして指定されうる多数パターンを自動生成するようなテスト手法 ユニットテストを補完するような役割にできるとよい
• The Laws of Identity
  #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
• スタッフエンジニアの道
  
• Known unknowns
  意識はしているが確信を持てないこと
• How GitHub used secret scanning to reach inbox zero
  #Security GitHub 社内の Secret Scanning 運用事例記事。15,000+ リポジトリで 20,000+ 件のアラートを 9 か月でゼロにするまでの段階的プロセスを公開している 初期アラートの 90%（18,000 件）はテストフィクスチャ由来のノイズ。5 リポジトリが全ノイズの大半を占めた 検出後の「ルーティング」が最大の課題。PAT などのクレデンシャル有効性確認・オーナーシップ特定・プレイブック整備の順で系統化した Push Protection を組織全体に強制適用（オプトアウト不可）することで再流入を防止 DevSecOps の実践例: 検出自動化に留まらず修復ワークフロー全体を自動化することが重要であると結論付けている 8 教訓: 生の件数を信用しない・組織横断で強制適用・クレデンシャル有効性確認を先行・メタデータ充実・永続的オーナーシップ基盤・検出後ワークフロー自動化・健全性メトリクス化・意思決定フレームワーク文書化 https://github.blog/security/application-security/how-github-used-secret-scanning-to-reach-inbox-zero/
• Datadog/

  pup
  #Observability Datadogのメトリクス、Logs、APM等をターミナルから操作するためのCLIツール。AIエージェントからの利用にも対応している 認証はOAuth2 (PKCE) によるブラウザ認証。APIキー環境変数にも対応 https://github.com/datadog-labs/pup
• Datadog/

  RUM
  Real User Monitoring #Observability Datadog上でRUMを提供する機能 APMと紐づける（以下、詳細）ことでフロントエンドで収集したデータをバックエンドのトレースと相関づけて追跡できる Connect RUM and Traces RUM Explorerでは、ユーザーセッションを1レコードとした探索が可能 https://docs.datadoghq.com/ja/real_user_monitoring/
• Datadog/

  Feature Flag Tracking
  #Observability DatadogのRUMの機能の一つとして提供されるフィーチャーフラグ可視化ツール フーチャーフラグ単位のグルーピングを行うことで機能リリースを安全に、迅速なトラブルシューティングが可能になる Flagsmithのようないくつかのツールで統合が容易になっている https://docs.datadoghq.com/real_user_monitoring/feature_flag_tracking/
• featureファイル
  #Testing Cucumberによって形式づけられたテキストファイル Gherkin記法で記述する
• Plan-and-Solve
  LLMに対して計画と解決という2段階の推論を行ってもらうプロンプトエンジニアリング手法でCoTと非常に似ている。 ReActと組み合わせるケースもある
• オポチュニティキャンバス
  #Product Management #Documentation Jeff Pattonが考案した、プロダクトの機会（オポチュニティ）を1枚で記述するためのキャンバス 仮説検証前のアイデア整理に用いられ、ユーザー価値とビジネス価値を並列に整理する 主な構成要素 Problems / Solution Ideas（課題と解決アイデア） Users & Customers（ユーザーと顧客） Solutions Today（既存の代替手段） User Value / Adoption Strategy（ユーザー価値と採用戦略） Business Problems / Benefits / Metrics（ビジネス課題・便益・指標） Budget（予算） https://jpattonassociates.com/opportunity-canvas/
• 仮説検証型アジャイル開発
  #Agile #Product Management 市谷 聡啓による仮説検証型アジャイル開発の資料 https://drr.red/
• Uber
• LeanとDevOpsの科学
  
• Swagger
  
• Strict-Transport-Security
  #Security/Cryptography HTTPレスポンスヘッダの一つ、Webサイトが常にHTTPSを使用していることをWebブラウザに認識させる
• モブプログラミング
  チーム全員が一箇所に集まって、1つの画面でプログラミングをする手法 ドライバーとナビゲーターに分かれる
• What Does Sponsorship Look Like?
  スポンサーシップについて論じているブログ https://larahogan.me/blog/what-sponsorship-looks-like/
• Working Agreement
  #Team Organization チームで決めたチームのルールのこと 価値観や行動規範を具体的に示す
• Shopifyはいかにしてモジュラモノリスへ移行したか
  Shopifyが大規模なRailsアプリケーションをモジュラモノリスへと移行した過程を紹介した記事。 Shopifyはいかにしてモジュラモノリスへ移行したか - InfoQ
• SCIM
  System for Cross-domain Identity Management #Security/Authentication ユーザーアイデンティティ情報を異なるシステム間で自動的にプロビジョニング・管理するための標準プロトコル 主な機能は以下の通り ユーザープロビジョニング（新規アカウント作成） デプロビジョニング（アカウント削除） 属性同期（ユーザー情報の更新） グループ管理 RESTful APIベースで、IdPとSP（Service Provider）間のユーザー情報同期を効率化する https://scimcloud.com/ https://datatracker.ietf.org/doc/html/rfc7644
• Spire
  #Programming #Security Scala言語の数値型ライブラリ。汎用的で高速かつ高精度な数値と、効率的な数値コードシンタックスを提供する。 Spire Introduction to Spire Numeric Programming in Scala with Spire JOTB19 - Numeric Programming with Spire by Lars Hupel
• OWASP Security Champions/

  Trust your champions
  OWASP Security Champions の成功原則の1つ 自律と裁量を与えることで、チャンピオンのエンゲージメントとオーナーシップを引き出す https://securitychampions.owasp.org/principles/05_Trust_your_champions/
• OWASP Security Champions/

  Start with a clear vision for your program
  OWASP Security Champions の成功原則の1つ 立ち上げ前に、プログラムの明確な目標と方向性を定める https://securitychampions.owasp.org/principles/02_Start_with_a_clear_vision_for_your_program/
• OWASP Security Champions/

  Secure management support
  OWASP Security Champions の成功原則の1つ リーダーシップの支持とスポンサーシップが、必要なリソースと組織的な権限を確保する https://securitychampions.owasp.org/principles/03_Secure_management_support/
• OWASP Security Champions/

  Reward responsibility
  OWASP Security Champions の成功原則の1つ 貢献を評価・報奨し、継続的な参加と質の高さを動機づける https://securitychampions.owasp.org/principles/08_Reward_responsibility/
• OWASP Security Champions/

  Create a community
  OWASP Security Champions の成功原則の1つ チャンピオン同士のつながりが協働を促し、プログラム全体を強くする https://securitychampions.owasp.org/principles/06_Create_a_community/
• OWASP Security Champions/

  Nominate a dedicated captain
  OWASP Security Champions の成功原則の1つ プログラムを統括・調整する単一のリーダーを置き、責任の所在と方向性を明確にする https://securitychampions.owasp.org/principles/04_Nominate_a_dedicated_captain/
• OWASP Security Champions/

  Be passionate about security
  OWASP Security Champions の成功原則の1つ セキュリティへの根本的な情熱が、実効的なチャンピオンプログラムの土台になる https://securitychampions.owasp.org/principles/01_Be_passionate_about_security/
• OWASP Security Champions/

  Anticipate personnel changes
  OWASP Security Champions の成功原則の1つ 人事異動を見越して計画し、プログラムの継続性と持続性を保つ https://securitychampions.owasp.org/principles/10_Anticipate_personnel_changes/
• OWASP Security Champions/

  Invest in your champions
  OWASP Security Champions の成功原則の1つ トレーニング・リソース・成長機会を提供し、チャンピオンの能力とコミットメントを高める https://securitychampions.owasp.org/principles/09_Invest_in_your_champions/
• OWASP Security Champions/

  Promote knowledge sharing
  OWASP Security Champions の成功原則の1つ 定期的な情報交換により、セキュリティの知見を組織全体へ広げる https://securitychampions.owasp.org/principles/07_Promote_knowledge_sharing/
• 認可/

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

  リソース
  #Security/Authorization 認可による保護対象
• 認可/

  主体
  Principal #Security/Authorization 認可チェックを受ける対象 ログインユーザーやAPIトークンなどがある
• SoR
  System of Record データの記録を重視するシステム、企業の業務基幹システム等が該当する