github リポジトリのREADMEにも書いていることではありますが、再掲します。

https://github.com/ultra-supara/homebrew-sisakulint

構築支援

JSONスキーマの準備

まず、正常な構文に関する情報が簡単に把握しやすくなるためのJSON スキーマを準備しておきましょう。VSCodeを利用している場合、任意の構文にカーソルを当てると構文に関する説明をしてくれたりドキュメントに誘導してくれたりするので便利です。既存のスキーマをsisakulintの指摘するルールに照合しやすくするために少しだけ改良したものです。以下をsettings.json に配置します。

"yaml.schemas": {
     "<https://ultra-supara/homebrew-sisakulint/settings.json>": "/.github/workflows/*.{yml,yaml}"
 }

そうすることで.github/workflows ディレクトリ配下のyamlファイルに対して設定したスキーマが適応されます。

テストとしてjobsのIDの部分にカーソルを持っていきました。以下のような結果を取得することができました。

スクリーンショット 0006-01-07 23.02.18.png

解析支援

クエリ処理分析に関して

sisakulintではいくつかのルールの内部実装でクエリ処理が入り込んでいるものがあります。これらはすべてOpen Policy Agentという団体が提供しているポリシー言語によって書かれており、その部分だけを切り出して試すことができます。これらのクエリ処理によるルールはいずれ、すべての機能がlinterの静的解析と統合されます。

Policy Language

基本的にはドメイン知識がセキュリティーやコンプライアンス項目に関してのルールを実装したという認識でOKです。Opan Policy AgentはCNCFのプロジェクトであり、その中でもSecurity & Complianceを解決するためのプロジェクトとして採択され開発されたものです。これを用いることでSecurity & Compliance以外のドメインを持つカスタムルールを実装することもできましたが本来の役割のscope内のものを実装するという方針でやめました。

スクリーンショット 0006-01-07 23.58.39.png

https://www.cncf.io/projects/ より

Security & Complianceに関するカスタムルール以外のものはほとんどがlinterの処理系の方で実装されています。

CIを起点とした脅威について