開発者がセキュアなコードを書けるように、
コードでトレーニングします。

観るのではなく、実践で学びます。

セキュリティ責任者がこのプラットフォームをどう評価するか。

購入担当者が一般的にSecureCodingHubをどう評価するか

構造化された評価を行うセキュリティエンジニアリングの責任者の多くは、同じような形で臨みます。4〜6週間のパイロット、15〜40名の開発者を擁する1つのエンジニアリングチーム、そして自社のSASTやペネトレーションテストレポートでの最近の検出結果に対応する脆弱性カテゴリーの絞り込みリストです。パイロットの目的は、プラットフォームが機能するかどうかではほとんどありません。開発者がプラットフォームに取り組むか、コンテンツが本番コードと比較して通用するか、そして測定のストーリーがCISOや監査人に対して説明できるほど信頼できるかどうかが論点です。

完了率ではなく正解率を測定することを推奨します。完了率は必須の期限を設定することで簡単に操作でき、開発者が自分のサービス内のインジェクションシンクを認識できるかどうかについてはほとんど何も教えてくれません。フェーズ1の検出における初回試行の正解率と、フェーズ2の正しい修正までの時間を組み合わせることで、四半期ごとに推移を追える、説明可能なシグナルが得られます。当社では両方のメトリクスを開発者別・トピック別に提供し、チームレベルおよびカテゴリーレベルで集計します。

パイロット中にもう1つ問うべき質問は、言語カバレッジが実際にチームが本番環境で書いている言語と一致しているかどうかです。Pythonのコンテンツが浅いのにスタックの半分がPythonであれば、紙の上のカバレッジにはほとんど意味がありません。当社はパイロット開始前にチームリードとコンテンツレビュー・セッションを実施し、割り当てられるモジュールが開発者自身のリポジトリで認識できる内容を反映するようにします。

既存のSAST・DASTと並存する形でのプラットフォームの位置付け

SecureCodingHubはトレーニング・プラットフォームであり、解析ツールではありません。SAST、DAST、IAST、SCAを置き換えるものではありません。お客様から聞いた最も明確な位置付けの説明は、スキャナーは開発者にどのバグを書いたかを伝え、SecureCodingHubは次のバグを書かない方法を教えるというものです。2つの領域は語彙を共有しています。SemgrepやSnykの検出結果でパストラバーサルのシンクがフラグ付けされたとき、それを修正する開発者はすでに割り当てられたカリキュラムでパストラバーサルのモジュールを完了しているはずです。

開発者セキュリティチャンピオン・プログラムを運用している組織にとって、プラットフォームはチャンピオン役割と自然に組み合わさります。チャンピオンが先に深いパスを完了し、その後チームのコードレビューの第一線として活動します。オンボーディング時に別途チャンピオン・トラックをスコープ設定し、レポーティング上で独立したコホートとして可視化することも可能です。

プラットフォームが意図的に行わないこと

明確にしておきたい点がいくつかあります。SecureCodingHubはCTFプラットフォームではありません。チャレンジは本番コードのパターンを中心に構築されており、人工的なフラグはなく、スコアボード文化もありません。開発者ごとに購入する単発コースのマーケットプレイスでもありません。ライセンスは組織単位またはシート単位で、カタログは1つのキュレーションされたライブラリであり、コミュニティアップロードのロングテールではありません。そして静的解析の代替品でもありません。評価基準にコードスキャン機能が含まれている場合、対象カテゴリーが間違っているため、最初のコールでその旨をお伝えします。

これを申し上げるのは、ミスマッチが双方にとって高くつくからです。1週目で終わるべきベンダー評価が四半期にわたって長引くと、お客様のチームと当社双方のカレンダーを浪費します。本製品は意図的に範囲を絞っています。1つのこと — 開発者が自分の言語で脆弱性パターンを認識して修正できるようにトレーニングする — を行い、それ以外の作業はスタック内の他のツールに委ねます。