SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

キーパーソンインタビュー

新用語「ASPM」とは? ソフトウェア品質を高めるためのセキュリティ最新動向を解説!

DevSecOpsやシフトレフトといった目標を身近にするASPMとは

 あらためてASPMとは何か。ガートナーは「開発パイプラインとコードリポジトリを統合し、脆弱なコンポーネントやパイプラインの誤設定を検出できるようにして修正ワークフローを調整し、開発パイプライン全体でセキュリティポリシーを施行できるようにすること」と定義している。言い換えるとASPMはパイプラインとリポジトリを統合し、そのうえで脆弱性や誤設定などの問題を検出可能な状態にして、全体で一括して管理できるようにするものとなる。

 ASPMを導入する目的には、アプリケーションとセキュリティの摩擦を軽減してDevOpsのスピードを高めること(裏返すと、セキュリティテストが開発のスピードを落とさないようにすること)、リスク管理体制を可視化し改善につなげること、そしてASTベンダーを削減し間接費用とTCOを削減できるようにすることにある。

 最後の部分は現状のASTの課題でもある。ガートナーの調査によると、43%以上の組織が10以上のASTベンダーを利用しているとある。多くの組織が、さまざまな理由で複数のASTツールを使い分けているのだ。これでは無駄にコストがかかるだけではなく、それぞれのアウトプットのフォーマットや基準が異なるため一貫性に欠け、無駄も生まれる。さらに深刻なのは複雑さから重要なリスクを見落とす懸念があることだ。

 過去と比べると、現在のアプリケーションには色々なところにセキュリティリスクが潜んでいることも忘れてはならない。大昔はコード管理は開発している会社内で完結していた。それだけ閉鎖的だった。しかし今ではオープンの恩恵を享受できるようになり、外部ライブラリを使えることでコーディングは独自のロジックなど最小限で済むようになった。その反面、外部の脆弱性の影響を受けるようにもなった。

 またクラウドを使うようになると、クラウド独自のリスクにも直面する。アプリケーションのコードには問題がなくても、シークレットをコード内に含めてしまっていたり、アクセス権など設定不備に起因するインシデントも起きている。これらは初歩的なミスと言えなくもないが、人間はミスをするものだし、ミスを検知する仕組みがなければ見逃しは起きてしまう。だからこそ機械的にチェックするツールが必要だ。

 開発者としても長い経験を持つシノプシス松岡氏は、理想的なASPMに求められる要素をいくつか挙げる。ASPMソリューションが他のツールと相互運用可能で統合を促進し、統一されたビューを提供できるような「オープン性」、開発者からセキュリティチームまで関係者がすぐ利用できるような「使いやすさ」、サポートする技術に「幅や深み」があること。また組織が統合やコスト削減を実現するような「柔軟」な価格やライセンス、ソリューションがTCO削減を実現できるように持続力や「安定性」、変化し続ける開発手法や脅威に追随して進化し続けられる「先見性」もあると望ましい。

開発組織がASPMを実施するために

 先述したとおり、多くの企業が多数のテストツールを併用することで非効率な状態に陥っている。テストにはさまざまな観点があり、それぞれに対応したツールを採用すると、結果のレポートやアウトプットもベンダーごとに異なる。同じアプリケーションをテストした結果、ツールごとに表記やフォーマットが異なることや基準が異なるなど、評価が分かれる場合も往々にしてある。開発チームはそうした矛盾や差異を対処するために工数を割かなくてはならない。

 こうした非効率性をなくすためには、あらゆるASTの結果を統合し、一貫性のあるポリシーでテストした結果を一元的に確認できるビューが必要だ。管理やレポートを統合できれば、開発チームに的確な優先順位をつけて修正依頼のチケットを発行することができ、セキュリティ改善にも繋がる。

 シノプシスのASPMソリューション「Software Risk Manager(SRM)」を例に見ていこう。まずは「テストの実行」では、いつ、どんなテストを実行したかを記録する。次にテストでセキュリティと品質について何らかの問題が発見されたら「テスト結果の相関」と「脆弱性の優先度付け」を実施し、どの問題を修正したのか履歴を記録することで「修正の追跡」を行い、最終的にはソフトウェアリスクの統合的なビューでリスクを一元的に可視化できる。松岡氏は「これでリスクが散在するということを防ぐことができます」と言う。

Software Risk Manager − AppSecリスクの包括的な可視化
Software Risk Manager − AppSecリスクの包括的な可視化

 具体的な手順としては、まずは現在使用しているASTツールやバグ追跡ツールをSRMと接続する。それに伴い、リスクを可視化するためのポリシーを整備していく必要もある。各種ツールがSRMとつながったら、次はテストをSRMに移管する。そうすればSRMにて一貫したポリシーに基づいてテストやチケット発行をシームレスに実施することができる。そしてテスト履歴などのソフトウェアリスクを一元的に確認することができるようになる。

 こうした仕組みがあると、制度変更や顧客からのリクエストなどで新たにテストを追加することになっても、全体の一貫性を保ちながら最小限の作業ですむように効率化が進むことが期待できる。

 松岡氏は「僕は還暦に近く、一からコードを書く時代も経験しました。しかし今では一からコードを書くことは少なくなりました。時代が変わり、欧米で規制が先行しているということは、やはり必要性があるからだと思います。問題がなければ規制なんて要りませんから。今の時代は新しいナレッジをみんなで共有しながら、みんなで改善していくことが求められていると思います。新しい考え方を採用していくことで、やるべき作業期間が短縮できたとしたらみんなにとっていい話ですよね」と話す。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
キーパーソンインタビュー連載記事一覧

もっと読む

この記事の著者

加山 恵美(カヤマ エミ)

フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレーターも担当しています。Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

小林 真一朗(編集部)(コバヤシシンイチロウ)

 2019年6月よりCodeZine編集部所属。カリフォルニア大学バークレー校人文科学部哲学科卒。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/18400 2023/10/25 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー