セキュリティ」カテゴリーアーカイブ

snyk を少し触ってみた

SecurityReportを読んだことで知った、snykというセキュリティプラットフォーム。
無料版もあるようなので、ちょこっと触ってみた

https://snyk.io/

凛々しいドーベルマンがトレードマークです。名前はPatch。

価格体系はこんな感じ。
ちょっと個人で使ってみるのであれば、Freeプランで十分なのではないかと思う。

何をセキュリティチェックやテストの対象とするのかは、結構選ぶことが出来る

基本的にはGithubなどのソース管理ツールを登録し、その中のプロジェクトを選ぶ形になると思う

せっかくなので試しに、過去にチュートリアル的に作って放置されているプロジェクトを対象に含めてみた

Code analysis ではミディアムが6件検知されているけど、問題はpackage.json。
作ってから放置されているので、そりゃ問題があるバージョンが定義されているんだろうな。

選択すると、何が問題かを教えてくれる。そこで「Fix this vulnerability」を選択する

一番下にある「Open a Fix PR」を押すと、自動でPRを作ってくれる。
ちなみに、出来ることと出来ないことはやっぱりあって、下の3つは自動では無理のようだ

expressのバージョンが変わったことがわかる。

無事に、驚異が取り除かれていることがわかります。

PRの作成まで自動でやってくれるのはいいですね。
あまり、この手のツールを使ったことがないので、snykが特別に優れているかどうか。比較という意味ではわかりませんが。。。

今回はCode analysis上は問題なかったですが、コード上での指摘も今度見てみたいですね。

自動検知設定

初回にGithubと関連付けた際に表示が出ていたのですが、snykでのチェックを自動的に走らせることが設定で出来ます

ここではGithubを選択した際の設定を表示しています。

例えば以下のような設定があります

  • 対象とするリポジトリはパブリックのみか、プライベートも含めるか?
  • インポートされたプロジェクトにセキュリティとライセンスの問題がないかどうか
  • 新たな脆弱性や既知の脆弱性を検知した際に自動的にPRを作るか
  • 脆弱性を修正するために、最新のベースイメージを使用するようにDockerfileを更新するPRを作るか

自動的に色々と検知してくれるのはいいのですが、そのたびにテストが走ることを考えると、それなりの規模で開発をされている方ではやはりFreeプランでは心もとないと思います。

最後に

これまで実際にセキュリティ系の製品を触っては来なかったので、なかなか新鮮ですね。
作って終わりというわけではなく、継続して開発していくことを考えると、このあたりの脆弱性を自動的に検知して知らせてくれるというのは心強いものです。

実際に、OSSを使わないなんてことは現実問題難しく、そのOSSが別のOSSを使っていて、更にその先で脆弱性が。。。なんて話はざらにありそうですし、それを「頑張って」で終わらせるのは厳しいものです。

製品全体を考えた際に、どのフェーズでどうやってこれら脆弱性に対する対抗策を整備していくのか。これからはしっかりと考えないといけませんね。

Cloud Security Report 2022 by snyk

Twitterを物色していたら、こんなものを見かけた

把握していなかったのだけど、セキュリティプラットフォームを提供するsnyk(スニーク)という企業があり、そこが出しているセキュリティレポートということ。
レポートの中身としては、エンジニアやセキュリティの専門家に対してのリサーチを行った結果をまとめたようなものだ

早速ダウンロードして読んでみた。
簡単な登録で読むことが出来るので、興味がある人は手にとっていただければと思う。

クラウドにおけるリスクの代表

開発者目線でクラウドのリスクって何かな?と考えると、やはり情報漏洩だろうな、と思ったらやはりそのあたりだった。

P4. serious cloud security

data breach(データ侵害), data leak(データ漏えい)、Environment intrusion(環境侵入)が多い。
もちろん、クラウドのダウンタイムも34%ということでリスクと言えばリスクだけど結局のところ対応しなければいけないリスクとしてはセキュリティなのだという。

もちろん、これは snyk というセキュリティプラットフォームを提供している企業が出しているレポートなので既定路線ではあるんだろうけど、考えなければ行けない大きなテーマであることには変わりない。

リスクへの対応

本レポートでは、それらセキュリティリスクに対応するためにIaC(infrastructure as code)を大きく取り上げている。

IaCはどちらかというと環境構築においての効率化的な側面のほうが開発者から見た場合には大きい。

初期の環境構築ではIaCで構築はするものの、実際に動かしていく中での追加変更は、クラウドコンソール上で設定変更していくスタイルだ。

レポートでは、それではダメなんだと。
問題への対応に関してもIaCを追従させていき、IaCに対してのチェックを行っていく必要性を掲げている。
そして、それに関しては、組織のポリシーに従った形であるかをチェックできるツールを使って監査・検査できるようにしていく必要があると。
更に、ポリシー自体もちゃんとコードで表すべきだと。

When security policies are expressed solely in human language and exist
in PDF documents, they might as well not exist at all

P.32 ALIGN AND AUTOMATE WITH POLICY AS CODE (PAC) より

思わず笑ってしまったのが上記、「ポリシーが人間の言葉でPDFとしておいてあるだけなんて、言ってしまえばなにもないのと同じじゃないか!」
うん、PDFなんて読まないよね。。。

IaCに関して

インフラの構築はだいぶ、コードによって管理できるようになっているのは間違いない。
クラウドの環境構築においてはもちろんのこと、Dockerやk8sなどのコンテナ環境に関しても基本は定義ベースで構築する形になってきている。

一方で、構築した後に手を加えることもよくあって、それは構築時のコードに反映されているだろうか?に関してはできているとは言えない場面もよくある。

特に、簡易的なクラウド構築に関してはなれないIaCでやるよりもクラウドコンソール上から実施したほうが早い気がするんだよね。

ぶっちゃけてしまうと、両方できなければいけないというのが答えになるんだろう。
ただ、その中でもIaCで環境を構築するということに慣れていき、そこに対してのチェックを行うことが出来るくらい知識が付けば、しばらくご飯は食べていけるのだろうと思った。