セキュア・コード・インサイト

For years, security leaders have invested heavily in secure coding programs, yet a fundamental question remains unanswered: Do we truly know who is committing code, and do they possess the skills required to write, review, and ultimately deliver secure code?

Traditional "shift-left" approaches leave enterprises struggling with massive blind spots when it comes to discovering and onboarding developers for secure coding programs. As program administrators rely on manual checks, spreadsheets and HR org structures to track developer secure coding skills, "shadow developers" who contribute code across critical code bases but lack security proficiency often emerge. This reality severely undermines secure SDLC goals and complicates governance, making it difficult to prove security competency when faced with internal or external reviews.

Secure Code Warrior’s Trust Agent eliminates this risk, transforming your secure coding program into a continuously monitored, verifiable defense that gives CISOs and AppSec leaders the confidence to prove their developers possess the necessary security proficiency required, on every commit.

Continuous Oversight and Assurance with Trust Agent

Without continuous oversight, developer risk remains hidden. Trust Agent delivers ongoing visibility by operationalizing security at the code commit level.

Continuous Developer Discovery: Knowing Your Scope

Before you can secure your codebase, you must know who is touching it.

Trust Agent automatically scans your integrated repositories to discover all active code contributors across your entire codebase. This helps address a critical challenge of onboarding - a continuous process - and answers the question: do you know when new engineers or contractors join, and whether they are receiving immediate, relevant secure coding education? By continuously monitoring commits, we ensure every developer is immediately identified and their secure coding journey can begin, eliminating the typical onboarding delays and ensuring comprehensive program scope.

‍

Verified Competency: Monitoring Code, Not Just Learning Completion

In addition to discovering all code contributors, Trust Agent transforms learning data into hard evidence by continuously monitoring secure coding skills applied in real-time. It provides deep observability by correlating every code commit with the developer's verified language-specific secure coding proficiency.

This is crucial for mandates like PCI DSS 4.0 (Requirement 6.2.2), which specifically calls for secure code training every 12 months in the language or framework developers commits code in. Trust Agent gives you the auditable evidence needed to prove that security competency is aligned with the languages and frameworks used in your critical applications.

In addition, Trust Agent provides immediate insights into your risk posture by pinpointing which teams or code repositories have high volumes of commits from developers without adequate security skills. This visibility enables program administrators to easily assign the right education to the right developers based on the most relevant, real-time data.

Integrated Governance and Policy Control

Ultimately, governance must be applied to truly lower developer security risk. Trust Agent offers the ability to make security proficiency mandatory by moving controls directly into existing dev workflows, with the ability to define commit policies based on your organization's risk tolerance. Trust Agent automates governance directly in the commit workflow, with policy gates that can be configured to log, warn, or block pull requests if a developer's secure coding skill level is insufficient. This integrated governance is the key to truly ensuring security is a requirement and not an optional suggestion.
‍

Securing the Future of Development

The move to verifiable secure coding proficiency is not just about passing audits- at the end of the day, it’s about shipping innovative, secure code. Even or especially with the rise of AI-assisted development, the fundamental principle remains: developers must be security-proficient to truly lower risk.  By making developer secure coding competency a measurable requirement, SCW Trust Agent is the critical piece that ensures your organization not only meets compliance and regulatory obligations, but fundamentally strengthens its security posture from within.

To learn more, book a demo or reach out to your Customer Success Manager today!

‍

AI 支援開発はもはや視野に入っていません。それが実現し、ソフトウェアの記述方法が急速に変化しています。GitHub Copilot、Cline、Roo、Cursor、Aider、Windsurf などのツールは、開発者を独自の共同パイロットに変え、より迅速なイテレーションを可能にし、プロトタイピングから大規模なリファクタリングプロジェクトまですべてを加速させています。

しかし、この変化に伴い、スピードとセキュリティというおなじみの緊張関係が生まれます。

Secure Code Warriorでは、開発者がAIコーディングツールを使用しながら安全に作業できるようにする方法について多くのことを考えてきました。 だからこそ、私たちはシンプルでパワフル、そしてすぐに役立つもの、つまり私たちの AI セキュリティルール — GitHub のすべての人が利用できる、無料で公開されているリソースです。 これらのルールは、Secure Code Warriorの顧客である必要はありません。これらのルールは、誰でも採用して自分のプロジェクトに拡張できる無料のコミュニティ主導の基盤として提供されています。

これらのルールは、開発者が猛烈なスピードで動いている場合でも、AIツールをより安全なコーディング手法へと導くガードレールの役割を果たすように設計されています。

急いでいる人のための要約：

Copilot や Cursor などの AI コーディングツールが現代の開発に不可欠になるにつれ、セキュリティを後回しにすることはできません。だからこそ、私たちは AI コード生成をより安全なデフォルトへと導くように設計された、軽量でセキュリティ重視のルールセットを構築しました。

• ウェブフロントエンド、バックエンド、モバイルに対応
• AIツールに簡単にドロップできます
• 公開されていて無料で使用でき、すぐに自分のプロジェクトに導入できます

ルールを見る → https://github.com/SecureCodeWarrior/ai-security-rules

キーボードに AI があっても、セキュアコーディングをデフォルトにしましょう。

1。AI アシストコーディングの時代にルールが重要な理由

AIコーディングツールは非常に便利ですが、間違いがないわけではありません。実用的なコードをすばやく生成することはできますが、特定のチームやプロジェクトの特定の標準、慣習、セキュリティポリシーを理解するためのニュアンスが欠けていることがよくあります。

ここで、プロジェクトレベルのルールファイルが役立ちます。

Cursor や Copilot などの最新の AI ツールは、コードの生成方法に影響する設定ファイルをサポートしています。これらのルールファイルは AI の耳元で次のようなささやき声のように機能します。

「このプロジェクトでは、SQL 文字列を連結することはありません。」
「安全でないデフォルトよりも安全なヘッダを使ったフェッチを優先してください。」
「セキュリティ監査が必要でない限り、eval () の使用は避けてください。」

これらのルールは特効薬ではなく、強力なコードレビュー手法やセキュリティツールに代わるものでもありませんが、AI が生成したコードを、安全な開発のためにチームがすでに実践している、または従うべきプラクティスと一致させるのに役立ちます。

2。私たちが構築したもの (そして構築しなかったもの)

スタータールールがご利用いただけるようになりました GitHub のパブリックリポジトリ。彼らは:

• ドメイン別に整理 — ウェブフロントエンド、バックエンド、モバイルを含む
  
• セキュリティ重視 — インジェクションの欠陥、安全でない処理、CSRF 保護、弱い認証フローなど、繰り返し発生する問題を網羅しています
  
• 軽量設計 — すべてを網羅したルールブックではなく、実用的な出発点となるように設計されています

AI コンテキストウィンドウがどれほど価値があり、コードがそれらのトークンをどれだけ早く消費するかを理解しているため、ルールは明確かつ簡潔に保ち、セキュリティに重点を置いています。私たちは、言語やフレームワークに特化したガイダンスを避けるという意図的な決断を下しました。その代わりに、アーキテクチャや設計について意見が分かれることなく、幅広い環境で機能する、広く適用可能で影響の大きいセキュリティプラクティスを採用しました。

これらのルールは、リファクタリングをほとんどまたはまったく行わずに、サポートされている AI ツールの構成形式に簡単にドロップできるように記述されています。これらのポリシーは、AI を安全なデフォルトに導くためのポリシーの出発点と考えてください。

3。新しい防御レイヤー

これは実際には次のようになります。

• AIがユーザー入力を処理するコードを提案すると、ベアプロセッシングではなく、検証とエンコーディングに傾きます。
  
• データベースクエリを作成するときは、文字列の連結ではなく、パラメータ化を推奨する傾向があります。
  
• フロントエンドの認証フローを生成する場合、AIは安全でないローカルストレージのハッキングではなく、トークン処理のベストプラクティスを促進する可能性が高くなります。

これはいずれも、継続的なセキュリティスキルの向上を含む、セキュリティプログラムにおける戦略的開発者リスク管理に取って代わるものではありません。また、特にLLMへの働きかけやAI生成コードのレビューが増えている中で、セキュリティに熟練した開発者の必要性がなくなるわけでもありません。これらのガードレールは、特に開発者が迅速に行動したり、マルチタスクを実行したり、あるいは単にツールを少し信頼しすぎたりしている場合に、意味のある防御層を追加します。

次は何？

これは完成品ではなく、出発点です。

AI コーディングツールが進化するにつれて、安全な開発へのアプローチも進化しなければなりません。私たちの AI セキュリティルール 自由に使用でき、プロジェクトに合わせて調整および拡張できます。私たちはこれらのルールセットを継続的に進化させることに全力を注いでいます。皆さんのご意見をお待ちしています。ぜひ試してみて、ご意見をお聞かせください。

GitHub のルールをご覧ください
SCW Exploreのルール使用ガイドラインを読む

AI支援コーディングは、すでにソフトウェアの構築方法を変えています。最初から安全であることを確認しましょう。

最近のほとんどすべての開発者チームは、企業が業界の枠組みや政府規制の範囲内にとどまっていることを確認するために使用される最初の認定プロセスの一部であるか、年次要件またはレビューの一部であるかにかかわらず、何らかの形のコンプライアンストレーニングを採用しています。これは重要なステップです。なぜなら、組織が基本的なコンプライアンス要件を満たせなければ、その従業員は現実的に職務を遂行できないからです。

コンプライアンスルールが存在するのには理由があります。なぜなら、そのルールが対象とする分野で働く人は誰でも、関連するすべてのプロセスと手順、および適用法について少なくとも基本的な理解を持っている必要があるからです。

コンプライアンストレーニングは重要ですが、義務付けられた最低要件を満たすだけでは、真のアプリケーションセキュリティは保証されません。これは、安全なコーディングスキルを日常のワークフローに取り入れようとしている開発者に特に当てはまります。ほぼすべての開発者が何らかのコンプライアンス研修を受けていますが、調査の結果、 67% が、コードに脆弱性を残すことが多いと回答しました。

なぜ?

セキュア・コード・ウォリアーは、2021年12月にエバンス・データ・コーポレーションと共同で「開発者主導のセキュリティ状況調査、2022年」を2年目に実施しました。世界中の1,200人の開発者を対象に、安全なコーディング手法に関するスキル、認識、行動、およびそれらがソフトウェア開発ライフサイクル（SDLC）に与える影響と関連性を理解しました。

コンプライアンストレーニングがソフトウェアセキュリティの向上につながらない理由という点では、これは私たちが長い間話し合ってきた問題です。最近の調査では、この問題が浮き彫りになっただけです。

一方で、開発者は、アプリケーションやプログラムのコードを最初に作成するときを含め、ソフトウェア開発プロセス全体にサイバーセキュリティを含めることで、新しい役割へのステップアップを求められています。しかし、安全なコードを書いたり、サイバーセキュリティの問題やそれに影響する可能性のある脆弱性についてすべて学ぶだけでも簡単なことではありません。調査では、開発者の 63% が、安全なコードを書くのは難しい作業だと答えています。

安全なコードを書くことの難しさは驚くべきことではありません。これだけ多くの高給のサイバーセキュリティ関連の仕事が満たされないのには理由があります。最後に数えたところでは、世界中で350万件を超える求人が出ています。それが簡単な仕事だったら、誰もがその分野に飛び込むでしょう。脅威と戦い、コード内の脆弱性を排除する方法を学ぶことは難しく、脅威の状況は絶えず変化しています。固定的なコンプライアンストレーニングや 1 回限りのクラスでは、開発者が必要とする教育についていけず、提供することもできません。コンプライアンスの観点からはチェックボックスになるかもしれませんが、組織に真のアプリケーションセキュリティ保証を提供したり、開発者が安全なコードを書いたり、コードの脆弱性を発見して修正するスキルを身に付けることはできません。

コンプライアンスとセキュリティのトレーニングは重要ですが、異なります

組織は、コンプライアンストレーニングで何ができるのか、何ができないのかを認識し、認識し始める必要があります。特に法律で義務付けられている場合は、コンプライアンストレーニングを放棄しないでください。特に、アンケート回答者の 92% が、コンプライアンス関連の問題やセキュリティフレームワークについて少なくともある程度のトレーニングが必要だと答え、50% が重要なコンプライアンス研修の必要性を強調しているためです。

彼らがトレーニングに最も関心を持っていたコンプライアンスフレームワークには、さまざまな業界固有のものが含まれていましたが、いくつかの一般的なサイバーセキュリティフレームワークもリストに含まれていました。その中には、CISセキュリティフレームワーク、PCI DSS、OWASPトップ10、MISRA C、ISO/IEC、医療保険の相互運用性と説明責任に関する法律（HIPAA）などが含まれていました。

もちろん、これらのフレームワークでトレーニングを行うことはできますが、コンプライアンストレーニングのチェックボックスにチェックを入れるだけでは、安全なコードを継続的に作成するための基盤を提供することにはならないことを理解してください。

その代わり、コンプライアンス・トレーニングは、開発者のセキュア・コーディング・スキルを伸ばす継続的な機会の一部と考えてください。コンプライアンス・サイクル以外でも繰り返すことで、開発者は安全なソフトウェアを毎日作成してリリースできるようになります。優先事項をコンプライアンスの達成から、開発チームが継続的に学習して安全にコーディングできるようにすることに移しましょう。開発者の支援に時間とリソースを投資することで、毎年実施されるチェックボックスのコンプライアンス演習や試験は、全体的な生産性の向上というメリットを得ながら、スタッフが簡単に合格して完了できるようになります。

どうすれば開発者主導のセキュリティに移行できるか?

圧倒的多数の開発者は、トレーニングは価値があると言いましたが、長年にわたって受けてきたセキュアコーディングに関するトレーニングの種類には異議を唱えました。開発者は、自分の仕事に関連する実際の例を使った実践的なトレーニングにもっと重点を置きたいと回答しました (30%)。また、回答者の 26% は、特にそれらの演習の一環として実際に安全なコードを書く練習ができた場合には、対話性を高めることが重要だと回答しました。

調査対象の開発者の 23% は、自分の業界やセクターで遭遇する可能性が最も高い特定の脆弱性に焦点を当てたガイド付きトレーニングをもっと受けたいと回答し、22% はトレーニングコースで実際の脆弱性の例をもっと見たいと考えていました。

静的で非インタラクティブなトレーニング（通常はコンプライアンストレーニングの経験）を提供するだけでは、開発者のセキュリティスキルを再現できるという点ではほとんど価値がないことは明らかです。代わりに、組織は、開発者が作業しながらセキュリティについて教えられる、ジャストインタイムトレーニングのようなものに重点を置くべきです。段階的な学習プログラムの導入を検討するのもいいかもしれません。

段階的なアプローチでは、通常、大きなトピックは個別の学習経験や概念に分解されます。開発者が進歩するにつれて、建物の高さが高くなるにつれて物理的な足場が構築されるように、すでに習得した概念の上に、より高度な概念が重ねられます。これにより、サイバーセキュリティのような困難で絶えず進化するトピックを教えるための実証済みの方法が生まれます。そのためには、まずそれをより小さく、それほど複雑ではない部分に分解し、その基盤の上にさらに複雑なものを構築します。

開発者のセキュリティスキルプログラムに取り組むことにしたとしても、それをコンプライアンス演習とは別にしておくことが重要になります。コンプライアンスとセキュリティトレーニングはどちらも重要であり、成功を収めるにはどちらも異なるアプローチが必要です。

さらに読むには

ホワイトペーパー:ソフトウェア・セキュリティを向上させるための課題 (および機会)

ホワイトペーパー: ソフトウェアセキュリティに対する開発者による予防的アプローチ。

レポート:開発者主導のセキュリティの現状。

The same 10 software vulnerabilities have caused more security breaches in the last 20+ years than any others. And yet, many businesses still opt for post-breach, post-event remediation; muddling through the human and business ramifications of it all. But now a new research study points to a new, human-led direction. 

‍The following discusses insights derived from a study conducted by Secure Code Warrior with Evans Data Corp titled ‘Shifting from reaction to prevention: The changing face of application security’ (2021) exploring developers attitudes towards secure coding, secure code practices, and security operations. Download the whitepaper here.

‍‍In the soon-to-be-released study, developers and development  managers were asked about the activities they associate with secure coding. The top three responses were:

• Using scanning tools on deployed applications.
• Manually reviewing code for vulnerabilities.
• The active and ongoing practice of writing software that is protected from vulnerabilities. 
  ‍

So what is this telling us? Two of the top three responses are still focused on reactive approaches, the first dependent on tooling (scanners), and second on the developer (i.e. human) performing manual checks – in both cases after the code is written. Vulnerabilities detected using these methods have to be kicked back to the development team for rework with knock-on effects on project timelines and project costs. 

At the same time, two of the three activities nominated rely on the human element – a pointer to growing perceptions of security as a human issue. But of all the activities nominated, the most telling is No. 3, which identifies the human factor in writing software that is protected from vulnerabilities in the first place.  This highlights a shift to starting left – a proactive and preventive approach that bakes security into software right from the start of the software development lifecycle. 

Reactive can equal EXPENSIVE

According to an IBM study*, it is thirty times more expensive to fix vulnerabilities in post-release code than if they were found and remediated at the beginning. That’s a powerful incentive for a new proactive and a more human approach to defense of software security that equips developers to code more securely, right from the start. 

This is what you could call a human-led defense. But to get developers to start caring about security, it has to become part of the way they think and code every day. This is a  call for new approaches to training that are hyper-relevant to developers’ everyday work and inspire them to want to learn – neither of which can be said of current training models.

To create a proactive security culture, new training is needed that:

• makes secure coding a positive and engaging experience for developers as they increase their software security skills 
• encourages developers to view their daily coding tasks through a security mindset 
• makes secure coding intrinsic to their daily workflow
  

When these threads come together, vulnerabilities are prevented from occurring in the first place, allowing teams to ship quality code faster, with confidence. The good news is that a Learning Platform already exists that 'starts left' in the software development process – one that is already empowering developers with the skills and tools to create quality code from the very start.
‍‍

‍

‍

‍

*IBM Software Group; Minimizing Code Defects to Improve Software Quality and Lower Development Costs
https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

この記事のバージョンが掲載されました ダークリーディング。ここで更新され、シンジケートされました。

セキュリティについて開発者と話すとき、私のモットーの1つは「品質の高いコードは安全なコードだけだ」ということです。これは変わりません。90 年代に脆弱なソフトウェアが世に出ていたとき、私たちは災害を免れたかもしれませんが、今日ではリスクを冒す価値はありません。多くの開発者が長年にわたり、開発者にセキュリティ意識を浸透させるために懸命に取り組んできました。そうすることで、コードの自己評価において、セキュリティが品質と同義語になることを願っています。

しかし、振り返ってみると（そして私の同僚の間でのいくつかの議論も）、それはおそらく概念を単純化しすぎているでしょう。確かに安全でありながら、初心者の開発技法の兆候や、理想的とは言えないその他の問題領域を示すコードを作成することは完全に可能です。

私たちの業界では、「左へのシフト」という概念について長々と語っています。私の考えでは、エンジニアリングチームがセキュリティ (品質の一面) に対する責任を分担できるようにし、共通の脆弱性を (文字通りの) 指先ひとつで消去する権限をエンジニアリングコホートに与えることが、残された「スタートアップ」に尽きます。しかし、現在のこの難問を踏まえると、限界をもう少し押し進める必要があるように思えます。

ある程度の品質のコードもその定義上安全ですが、すべての安全なコードが必ずしも高品質であるとは限りません。純粋に安全なコーディング標準を確保するには、「左から左へ」から始めるのが公式なのでしょうか？

「質の悪い」セキュアコードとはどのようなものですか?

このコードスニペットを拡大鏡で見てみましょう。

セキュリティの観点からこのコードを分析すると、このスニペットは確かに安全であり、攻撃者が SQL Injection の脆弱性を悪用するための入り口にはなりません。

高品質のコードの例ですか？残念ながら、実際にはそうではありません。引数を a から単純に変更しただけです ミント (エーガー) に ストリング value では、自由形式のユーザー入力でクエリを操作できます。これに対し、数値では操作できません。その変更、あるいはどこか別の場所から String sql を無計画にコピーして貼り付けると、SQL インジェクションの脆弱性とそれに伴うすべてのリスクが発生する可能性のある環境がすぐに作り出されます。

ここではセキュリティ対策の範囲が非常に限られていましたが、より徹底した (または経験豊富な) 開発者は別のアプローチを取り、非効率的な引数構造の影響について検討した可能性があります。このようなコードの公開は、不適切なやり方であるだけでなく、開発コホートの他のメンバーにとっても悪い手本となります。

ソフトウェア「三重の脅威」：形態、機能、要塞のような？

エンターテインメント業界における「三重の脅威」とは、演技、ダンス、歌を同等に高いレベルのスキルで発揮できる個人です。彼らはオーディションのたびに恐れられ、うらやましく思われる人々であり、すでに競争の激しい業界のユニコーンなのです。どの業界にも独自のトップクラスの優れた製品とサービスがありますが、ソフトウェアも例外ではありません。

同等の (高品質) 品質でバランスを取るのが難しいアプリケーションの 3 つの重要な要素を考えてみると、それらは機能性/エレガンス、強固なセキュリティ、そして要求される配信速度を考慮した際の費用対効果です。さて、最後の属性は、間違いなく他の2つの選択肢がどの程度うまく適用されるかを決定づける要因であり、時間の経過とともに全体的な品質が低下するきっかけにもなり得ます。

しかし、すべてのソフトウェアがヒュー・ジャックマンのように動作する必要があるのか、それともニコラス・ケイジとうまくやっていけるのか？言い換えると、ウルヴァリンをチームに入れることができれば、ベストを尽くすことになります。

マーティン・ファウラーが質問しました 高品質はコストに見合う価値がありますか？ ソフトウェア開発では、「それだけの価値がある」だけでなく、時間が経つにつれて実際には安価になったと結論付けました。ほとんどのユーザーは、コードがめちゃくちゃかどうかや、セキュリティが他のすべてと同じくらい重要視されているかどうかを内部から調べることはないでしょう。しかし、ツールを利用している人は、新しい機能を追加するためにずさんなコードをやり直したり、何が起きているのかを理解するためにプロジェクトの主要部分を調べたり、あるいは最悪のシナリオ、つまりAppSecチームから戻ってきて生産を遅らせた脆弱性の修正に貴重な時間を浪費することになります。コードを安全かつ高品質にするために今時間を費やすことで、不適切に実行された作業を解明するコストは言うまでもなく、将来の悩みの種となる多くの問題を解決できます。

熟練したセキュリティ意識の高い開発者は、エンジニアがプロセスの各段階で制御できる一般的なセキュリティ上の落とし穴を取り除くことを考慮しながら、機能提供における創造的で問題解決のビジョンを維持したコードを書きます。安全なコードは単独ではそれほど効果的ではありません。だからこそ、「左から左」から始めるという概念が、リスクを抑えながら素晴らしい機能を提供する能力に組み込まれた、開発者にとって身近な存在としてのセキュリティ文化を支える助けとなるのです。

安全なユーザーエクスペリエンスには、「左から左」から始めることが重要です。

セキュリティは長い間、ソフトウェアのユーザーエクスペリエンスにおいて考慮されてきましたが、結果は明らかにまちまちでした。セキュリティの設定ミスが原因でした。 クラウドベースのデータ侵害の 21% 過去1年間、パスワードをプレーンテキストで保存するなどのアマチュアアワーのミスにより、影響を受けた企業の生産性、収益、顧客の信頼が著しく低下しました。

さらに、ユーザー自身が自分のデータを保護することになると、ユーザー自身が最悪の敵になる可能性があります。 人が多すぎる 依然として「パスワード」をパスワードとして使用しているか、複数の機密アカウントで同じ組み合わせを使用しています。

ログイン画面で作業しなければならないと言われたときに慌てて判断する開発者は誰もいません。それも不思議ではありません。堅牢で機能的なセキュリティフローを設計し、ユーザーが混乱を最小限に抑えながら意味のある方法でナビゲートできるセキュリティフローを設計するのは微妙なバランスです。

複雑な手順や制限が多すぎると、ユーザーは二度と戻らないように切り替える可能性があり（新しいアプリにとっては災害）、混乱を招きすぎて、アカウントにアクセスしようとするユーザーからの問い合わせに対応する際に、サポートチームが集団的な片頭痛に陥る可能性があります。簡単にしすぎると、セキュリティの部分で失敗しているようなものです。

セキュアなユーザーエクスペリエンスを成功させるには、厳密なセキュリティを理にかなったフローに組み込む必要があります。このフローは、ソフトウェアの魅力である他の要素をすべて損なうことのない方法で提示する必要があります。複雑なパスワード要件、CAPTCHA、ミニボス、4波のゾンビなど、安全なログイン機能をコーディングするという目的は確かに達成できますが、それがユーザーにとって嫌な完全に混乱しているとしたら、それは的外れです。

ソフトウェア・エクセレンスの基礎を築きましょう。

私自身開発者として、私たちの大多数は自分の仕事に誇りを持っており、正しいことをしたいと思っていることを知っています。時間の制約、現在の目標の突然の変更、緊急のホットフィックスなどの厄介なカーブボールは、フローを混乱させ、間違いにつながる可能性がありますが、厳しい真実は、多くのソフトウェアエンジニアが成功するための準備が整っていないということです。

「左から左」から始めることは開発者第一の概念であり、組織はエンジニアリングチームの向上に真剣に取り組む必要があります。セキュリティ意識の高い開発者はそれだけの価値があり、トレーニング、適切なツールの提供、経験豊富な開発者からの指導を受ける機会という形でのサポートを受けることで、ソフトウェアを次のレベルに引き上げるために必要な正確さと細部への配慮を備えた、セキュリティ第一の考え方でコードを作成する環境が育まれます。

あなた自身でセキュア・コーディングの火をつける準備はできていますか？ 挑戦に立ち向かえ。

‍

今は（とにかく、私たちにとって）特別な時期。最近太陽の周りを走った直近のラップと、成長、教訓、そして避けられない予測不可能な新年に向けて準備を整えるために、過去365日間に何が行われたかを振り返ります。

去年の波乱を予見できた人は誰もいなかったと思うけど、結局のところ、私たちのほとんどはLAドジャースよりも多くのカーブボールに直面していたと思いますが、私たちはまだここにいます。カレンダーが刻々と過ぎたからといって、「名前が付けられない年」の問題点が突然止まったわけではありませんが、私の周りには、個人、企業、そして業界における揺るぎない回復力が見られます。

では、銀河全体でコードを保護するという私たちの目標はどのような進歩を遂げましたか？

製品スイートをさらに充実させました。

Secure Code Warriorトレーニングプラットフォームは、常に当社のサービスの中心であり続けますが、より多様で、より多くの開発者が選択するツールの作成に努めることが私たちの最優先事項です。

私たちは、すべてのチームが自信を持って高品質のソフトウェアをリリースできるようにする、予防的で安全なコーディングアプローチを採用するよう開発者に促したいと考えています。

当社の製品チームがこれまで懸命に努力して展開してきたことを詳しく説明できることをとても誇りに思います。彼らは一年中素晴らしい目標を達成してきました。

• Adversary.ioを買収し、9か月足らずで彼らのテクノロジー、驚くほど熟練したチーム、企業顧客を統合しました。
• 私たちはサポートという信じられないほどのマイルストーンに到達しました 50 以上のプログラミング言語には、Docker、Ansible、Terraform、Kubernetes、Powershell、CloudFormationなどのコードの主力としてのインフラストラクチャだけでなく、RustやGoなどの新しいインフラストラクチャも含まれます。
• まったく新しいものをリリースすることで、開発者にセキュリティ知識をもたらす 拡張子 GitHub のアクションと課題に対応。さらに Atlassian JIRA Cloud & Server では、タスクを切り替えることなく、開発者がその場で状況に応じた学習を行うことができます。
• IDE でのリアルタイム品質コードガイダンス 先生、でご利用いただけるようになりました ジェットブレインズマーケットプレイス すべての開発者がセキュリティバグを検出し、ベストプラクティスを実施し、知識を共有し、パフォーマンス上の問題や技術的負債を防ぐことができます
• リリースすることで、企業が開発者と関わりやすくなり、安全なコーディングを拡大しやすくなります コースは、組織とそのセキュリティ目標に最も関連する目的のための厳選された学習経路を可能にするまったく新しい機能です。また、以下も追加しました。 ミッションは、フラッグシッププラットフォームのエキサイティングな拡張機能であり、開発者をエクスプロイトのパイロットの対象にします。これは、開発者に成功のための実行可能な生涯にわたる基盤を提供するための足場型学習アプローチの次のステップです。

... コーディング初心者をご存知の方は、無料アプリSecure Code Bootcampをチェックして、セキュリティへの取り組みを始めましょう。

私たちは上陸し、事業を拡大し、影響を与えました。

私たちはセキュアコーディングへのアプローチを少し変えたいと思っています。当然のことながら、この精神が業界全体に広まることを期待しています。開発者がサイバー攻撃者としっかり戦う能力を認識することは重要であり、実際にセキュリティについて学ぶことを楽しんでもらうことが第一の目標です。

世界中から何千人もの開発者がバーチャルトーナメントに参加し、2020年だけで80を超える開発者が開催されました。参加者に参加してもらえたことにワクワクしました。 GitHub ユニバース、グローバル シスコ イベント、および DevSecCon。

データを掘り下げてみると、2020年には数十万人のユニークユーザーが当社のプラットフォームでプレイしていました。6年前に始まったことを考えると、これは驚くべきことです。

フォーチュン1000企業の間で当社のリーチが大幅に拡大し、それぞれがセキュリティプログラムの一環として新しいことに積極的に取り組んでいることを非常に嬉しく思います。特にテクノロジー企業との相乗効果が見られました。その多くはリモートワークに軸足を移し、リモートトレーニングの選択肢に価値を見出していました。

チーム・オーサムは力を合わせてより大きく、強くなった。

過去1年間に当社が企業として経験した最大の変化の1つは、アイスランドを拠点とするサイバーセキュリティ企業であるAdversaryの買収でした。私たちには多くの共通点がありました。それは、サイバーセキュリティに対する人を中心としたアプローチ、価値観の調整、補完的な製品に対する同様のスタンスです。私たちは彼らのチームを私たちのチームに迎え、素晴らしい人材の中からかけがえのない専門知識と才能を獲得しました。

また、グローバルセールス担当上級副社長としてジョン・ウィルソンを迎えました。これは、成長を促進し、クラウドテクノロジーとサイバーセキュリティ企業をマーケットリーダーに育ててきた25年にわたる豊富な実績の恩恵を受けたものです。彼の幅広い技術的スキルは、シマンテック、クオリス、ブラックベリー、ベライゾンなどの企業で革新的な力を発揮してきました。彼が私たちと一緒に魔法を働かせてくれたことは、これ以上ないほど幸せなことです。

物理的なオフィスがないからといって、5か国で60人の新入社員をオンボーディングし、バーチャルサポート、紹介、そしてもちろん、誰もが欲しがる従業員グッズパックを玄関先に届けて、彼らがすぐに着手できるようにしました。

私たちはすべての部門で成長を続け、品質の高いコードを迅速に実現するというグローバルな使命を達成する上で同じくらい重要でした。それでも、まだ始まったばかりだと感じています。

2021年、話題が変わる年。

私は長い間、社会はサイバーセキュリティを十分に気にかけていないと感じていました。そして、信じられないほど劇的なことが起こったときになって初めて、行動と認識の針が動くのが見えるかもしれません。

昨年末にSolarWindsの大規模なセキュリティ侵害が発生したため、詳細が明らかになりつつあります。被害の全容はまだわかっていませんが、この事件は広範囲にわたる変化のきっかけとなる可能性があります。米国政府機関はすでにセキュリティプログラムの見直しを進めており、サイバースパイ活動は失うものが多い部門の間では非常にホットな話題です。

何をするにも少しでも楽しいことはできますが、今こそ袖をまくり上げて、会話を真に変えることに取り組む時です。

セキュリティ意識の高い開発者は皆、サイバー攻撃から私たちの世界を少しでも安全にします。成功するための知識、そしておそらくそれを気に入ってもらうための知識を提供することが、私たちの目標は常に私たちの目標です。私たちは、開発者がセキュリティについて学び、最高品質のコードを作成するときに使用するツールを開発するために、日々懸命に取り組んでいます。安全なコードは標準であるべきであり、それを実現するためには私たち全員が手を貸すことができます。

サイバー犯罪という巨大で複数の脅威に世界がどのように取り組むべきかを議論する記事、イニシアチブ、委員会が無数にあり、「サイバーセキュリティコンプライアンス」は長年にわたってトレンドになっているように感じます。

問題は、私たちが作っていないようだということです それを 大いなる進歩。世界的に見ると、データ漏えいによるコストは着実に増加傾向にあり、5年間で 12% 増加し、ほぼ解消されました。 392万米ドル 1 件あたりの違反件数 2019年に。わずか数十年の間にインターネットの利用が爆発的に拡大したため、多くの企業は、急速にオンライン化して店舗を立ち上げ、安全でないソフトウェア、限られたアプリケーションセキュリティリソース、場合によっては顧客からの信頼の悪用による影響に対処し、対策を講じることなく戦うしかありませんでした。

最近、私たちは反論の余地のないほど成熟しています。私たちは脅威の範囲を理解し、詳細に議論しています。企業はサイバー攻撃が顧客センチメント、自社の評判、収益に与える影響を十分に認識しており、多くの場所がコンプライアンストレーニング、熟練した雇用、そしてますます増えているDevSecOpsイニシアチブを通じて、ソフトウェアセキュリティの向上を積極的に模索しています。このような大きな飛躍にもかかわらず、私たちはこの戦いに勝っているわけではなく、間近に迫っているわけでもありません。少なくともあったことはある 40億件の記録が盗まれた 2019年のデータ漏えい件数だけでも

欠けている要素の1つは、サイバーセキュリティ基準、期待、および侵害の結果について（政府レベルで）いくぶんゆっくりとしたトリクルダウンがあったことです。の出現 GDPR 少なくともヨーロッパでは、一部の首脳が集まり始めていますが、多くの政府機関が追いつき始めたばかりであり、新たに開花したコンプライアンスイニシアチブに迅速に従うことが突然必要になったことで、将来的に望ましくない影響が生じる可能性があります。

愚か者は突っ込んで（間違った訓練を受ける）

という形での確固たるガイドライン ニスト、新しい規制 ニューヨーク州 そしてその形成 英国サイバーセキュリティ評議会 私たちのデータを安全に保つために善戦を戦っている人々にとって、これらはすべて途方もない勝利でした。彼らは現在のソフトウェア開発における問題を認識し、セキュリティのベストプラクティスの観点から、倫理的でコンプライアンスに準拠していると見なされるために現在満たさなければならない基準について組織を導くための措置を講じています。

残念ながら、この段階では、最も重要な要素のいくつかは少し解釈の余地がありません。たとえば、英国サイバーセキュリティ理事会の法律で義務付けられているのは、以下のとおりです。

「すでに実施されているキャリアパスの取り組みに基づいて、認定資格の明確なリストと、それらがどのように相互に関連し、どのような能力が発揮されるかについてのわかりやすいフレームワークを作成すること。」

彼らの取り組みは間違いなく時間とともに改善され成長しますが、組織がすでにパニックに陥り、今トレーニングに飛び込んでいるのであれば、将来に向けた準備が整っていないことに気付くかもしれません。

組織のサイバーセキュリティに対する要求は急速に変化しており、静的なトレーニングソリューションが安全でないソフトウェアの流れを必要な速度で阻止することはまずありません。状況は、従来のコースでは更新できないほど速く変化しています。そのため、一部の場所は「チェック・ザ・ボックス」のコンプライアンス演習の罠に陥る可能性があります。開発者、請負業者、その他のセキュリティ専門家は十分なトレーニングを受けられず、私たちはただのダック状態に戻っています。

静的トレーニングと静的ツールには同じ問題があります。

静的分析ツールはSDLCの不可欠な部分であり、ほとんどの大規模組織に見られる希少で過労なAppSecスペシャリストをスキャンする主力ツールとしての役割を果たしています。これらのツールはうまく機能しますが、欠点があります。「1つの」ツールですべての脆弱性をスキャンすることはできず、世の中の膨大なプログラミングフレームワークをサポートできるわけではありません。また、これは時間のかかるプロセスでもあり、1 つのセキュリティバグが侵入するだけで、攻撃者に門戸を開けることができます。

静的トレーニングでも同様の問題があります。開発者が厳密な「1回限りの」コースとしてセキュリティトレーニングを受けたとしても、その期間に最も蔓延しているセキュリティ問題に遅れずについていける可能性はほとんどありません。このコースは執筆時点のスナップショットであり、学生が好む言語とフレームワークで提供され、十分に再検討されることはほとんどありません。また、日常業務で直面する可能性のある脆弱性に関連する内容でもありません。数か月前に視聴した動画から関連情報の 1 つを思い出し、配信期限に間に合い、コードを公開しようとしていることを想像してみてください。そんなことは起こりそうにありません。

多くの業界で従来の教育方法が見直されていますが、開発者向けのセキュリティトレーニングに関しては、私たちがまだ経験している膨大な量のデータ漏えい（特に、コーディングで何十年にもわたって回避する方法を知っている脆弱性のせいにできるもの）を見るだけで十分です。 SQL インジェクションのような）別の方法を試さなければならないことを理解するには。

サイバーセキュリティのベストプラクティスの絶え間なく変化するニーズに柔軟に対応できる、単一の直線的なコースの範囲を超えて、トレーニングが必要です。

ダイナミックトレーニング:ゴールドスタンダード

ビジネス、個人のスキルレベル、一般的な業界動向に合わせて迅速に形作ることができる動的なトレーニングソリューションを開発者に提供することで、安全にコーディングし、セキュリティを最優先に考え、セキュリティを意識して行動するための最適な基盤を開発者に提供できます。

誰にでも当てはまる、一度も見直さず、最初から取り組まないトレーニングは、完全に時間の無駄になります。残念ながら、コンプライアンスのために効果のないプログラムを衝動買いしてしまう可能性があります。導入する前から時代遅れになっていたり、日常業務のニーズとほとんど関係がない場合もあります。

ダイナミックトレーニングは、日々のニーズに合わせて常に更新され、ユーザーの批判的思考を促す生き生きとしたツールです。 実際にスキルを学び、問題を解決する力を与えてくれます。

では、セキュリティの観点から見たダイナミック・トレーニング・プログラムはどのようなものなのでしょうか。

次のようになります。

• 一口サイズ: 開発者は、長々としたトレーニング資料やビデオよりもはるかに覚えやすい（そしてもっと重要なのは適用しやすい）管理しやすいまとまりでスキルを習得できる
• 関連する: 開発者が主にJavaでコーディングする場合、例がC＃などにある一般的なセキュリティトレーニングは何の役に立ちますか？どのようなトレーニングも開発者の役割に直接適用して、コーディング中に何を見つけて修正すべきか (そして理想的にはそもそも避けるべきか) を見極めることができるようにすべきです。
• 現在: これは当たり前のようですが、多くの場合そうではありません。サイバーセキュリティ環境は常に変化しており、コードが増えるほど責任も増えます。開発者が防御の最前線に立つためには、最新のセキュリティベストプラクティスを常に把握できるトレーニングが必要です。
• 魅力的: 開発者が「セキュリティ」を面倒に感じることは周知の事実です。特に、それがクリエイティブな流れを妨げる場合はなおさらです。適切なトレーニングを受けることで、大きなリスクになりかねない日常的なセキュリティ問題を解決する能力を身につけ、責任とセキュリティ意識の文化を築くことができます。
• 楽しい: ダイナミックトレーニングが退屈なことはほとんどありません。設計上、少なくともある程度は刺激的であるはずです。開発者が好きなことについて考えてみてください。問題解決、同僚、そして私たちの多くがそうであるように、労働力、報酬、表彰において競争することです。彼らの強みを活かして、最高の結果を得ることに集中しましょう。

今はソフトウェアエンジニアにとってエキサイティングな時代です。彼らはデジタルイノベーションに不可欠な役割を果たし、素晴らしい企業を作る手助けをし、さらには自分の作品で世界を席巻することさえあります。しかし、政府機関や大企業がソフトウェア・セキュリティの基準を設定するうえで果たすべき役割を認識している今、官僚的なチェック・ワークではなく、安全なコーディングへの愛情を育む効果的でダイナミックなトレーニング・ソリューションで支援することが重要です。

IBMの調査によると、リリース後に脆弱性を修正する方が、最初に脆弱性を発見して修正する場合の30倍の費用がかかります。これを念頭に置けば、将来を見据えたCIOが安全なコーディング手法を実装しているのは当然のことです。つまり、最初からより安全なコードを書けるように開発者を訓練し、身につけること、つまり開発者を組織の「最前線」にすることを意味します。この傾向の実際の影響を測定するために、Secure Code WarriorはEvans Data Corp*と協力して、安全なコーディング、安全なコード慣行、およびセキュリティ運用に対する開発者の態度に関する最近の調査を委託しました。この調査により、セキュア・コード・プラクティスの導入は、さまざまな面で企業にとって変革をもたらすことが明らかになりました。ホワイトペーパーをダウンロードしてください。 ここに。

より自信とマインドフルネスを備えた安全なコーディング

間違いなく、安全なコーディング手法を実装することで、開発者のセキュリティ意識が高まり、雇用主に利益がもたらされます。私たちの調査によると、開発者の 55% は、適切なトレーニングによってコーディング技術に対する自信が高まったと答え、53% は、適切なトレーニングによって自分のコードのデバッグやテストをより慎重に行うことができるようになったと答えています。これと同等の回答者の 53% が、コードを書く際にセキュリティにもっと気を配るようになったと考えています。

これは何を教えてくれますか？これは、少しのスキルを向上させれば、開発者が防御の最前線に変身できることを示しています。

よりスマートなツール選択+リリース速度の向上

マネージャーにセキュアコードトレーニングの影響について尋ねたところ、彼らの視点は彼らの管理責任を反映していました。マネージャーの43％は、セキュアコードトレーニングにより、組織がコードのデバッグとテストをより慎重に行えるようになったと回答しました。47％は、優れたトレーニングにより、よりセキュリティを提供するツールをより選択的に選択できるようになったと回答しました。しかし、おそらく最も重要なのは、44% が、安全なコードトレーニングとテクニックが時間の節約とソフトウェアリリースのスピードアップに役立ったと回答したことです。これは、市場投入までのスピードがすべてである場合には大きなメリットです。

全面的な生産性の向上

安全なコーディングが生産性にどのように役立ったかを開発者に尋ねたところ、半数以上がコーディングとアプリデザインの品質の両方を向上させるのに役立ったと感じました。

63% が、繰り返し発生する脆弱性を防ぐことでやり直しが減ったと答えています。70% が、やり直しやパッチにつながるエラーを排除できたと答えています。56% が、デバッグとテストの生産性が向上したと回答しています。ソフトウェア開発ライフサイクルの複数の段階で変革が進行中であることがわかります。

チームダイナミクスとコード品質

安全なコードプラクティスは、チームのダイナミクスにも影響を与えます。開発者は個人でより安全にコーディングする方法を学びますが、開発者が開発したコードは孤立した状態には存在しません。開発者が開発したコードは他の人の作業に依存している場合が多く、その逆も同様です。セキュア・コーディング・プラクティスを実装することで、開発者はセキュア・コーディングの知識を共有して探すようになり、開発者、開発者、経営陣、開発チームとその利害関係者間のコミュニケーションが円滑になります。

• 調査対象の開発者の 60% は、安全なコードプラクティスを採用することで、他の開発者とのコミュニケーションが向上したと考えています
• 45％が、経営陣との接触が増えたと答えています。

マネージャーの意見は、視点は異なるものの、こうした意見に共感しています。調査対象のマネージャーの 62% が、安全なコードプラクティスでは、人員管理により多くの時間を費やす必要があり、コードリリースのスピードを上げる必要があると回答しています。

安全なコードプラクティスを導入している組織にとって、コミュニケーションの増加はチームのダイナミクスに変革をもたらし、コードの品質と市場投入までのスピードにプラスの影響を与えます。

事後対応型から予防型への変革

最後に、安全なコードは、開発者と開発マネージャーがセキュリティ対策を適用する方法とそれに付随する指標に影響を与えます。

今日でも 81% の組織が、セキュリティ品質を判断する際に、欠陥数やスキャナーメトリックなどの事後対応型の指標に頼っています。

しかし、こうした事後対応型の活動は、予防的指標や予防的指標によって補完されたり、それに取って代わられたりすることが増えています。現在、67% の組織が、OWASP Top 10に対する開発者の認知度をセキュリティ対策の指標として測定しています。使用が増えているプロアクティブな指標には、他にも次のようなものがあります。

• アプリケーションセキュリティに関する開発者の能力の測定
• 事前承認コードの使用
• 規制要件の遵守。

現在、開発者の90％がこれらの予防策に注意を払っています。しかし、安全なコーディング手法に対する認識と実装が高まっている一方で、その可能性を最大限に引き出すにはまだいくらかの道のりがあります。

ここからどこへ行く？

Secure Code Warriorは、セキュアコーディングにおける変革の推進者として、開発者を第一線の防衛線に変え、全体的なセキュリティアプローチを事後対応型から事前対応型へと変革させるために、人間主導のアプローチを採用しています。当社の実績ある学習プラットフォームでは、開発者が現実世界で直面している課題を模倣した課題を取り入れた、言語やフレームワークに特化した52のカテゴリーで、状況に応じた実践的な教育を行っています。深い経験から、開発者は理論に基づいた静的学習の苦労よりも、実践による学習方法を好むことがわかっています。これがチームにもたらす変革的な影響と、品質の高いコードを自信を持ってリリースする能力について知りたい場合は、 今すぐデモを予約。

‍

*対応から予防への移行:アプリケーションセキュリティの様相は変わりつつあります。セキュア・コード・ウォリアーとエバンス・データ・コーポレーション 2020
1。IBM Software Group; コード欠陥の最小化によるソフトウェア品質の向上と開発コストの削減- https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

‍

チーム内でのクックブックの共有

ある人がコードの品質や生産性を向上させるためにSenseiレシピを作成した場合、クックブックを共有することでチームの全員が恩恵を受けることができます。

Senseiは、料理本を共有するためのさまざまなメカニズムを提供しています。

• バージョン管理下のプロジェクトにクックブックを保存
• クックブックを共有フォルダーに保存する
• クックブックを Github に保存する
• HTTP (s) 経由で圧縮されたファイル

Senseiはクックブックを共有することで、チームが協力して知識を共有できるよう支援します。このコラボレーションは、コミュニケーションを改善し、合意されたコード品質アプローチを組み込むのに役立ちます。

たとえば、料理本の共有:

• チームメンバー同士が役に立つレシピを共有するのに役立ちます。
• チームリーダーが合意されたコーディングプラクティスを体系化し、ジュニアスタッフ向けにサポートします。これにより、一般的な違反を特定し、合意されたバージョンを迅速に修正できます。
• チーム間の協力の強化を促進します。たとえば、AppSecチームがコード内の問題を浮き彫りにするレシピを作成し、開発チームがクイックフィックスを書くことができます。

次のいくつかのセクションでは、それぞれの共有メカニズムを実装する方法について説明します。

バージョン管理下のプロジェクトにクックブックを保存

プロジェクト.sensei フォルダは、クックブックファイルを作成する際のデフォルトオプションです。

• `プロジェクト://.sensei`

すべてのクックブックとレシピは、プロジェクトの.senseiフォルダに保存されます。

共有する最も簡単な方法は、プロジェクトの.senseiフォルダをバージョンコントロールに追加することです。

これで、.sensei フォルダーは、プロジェクトに関連する他の共有コードアーティファクトと同様に管理できます。クックブックは YAML 設定として保存されるため、コミットやレビューのプロセス中に簡単にマージできます。

これがパブリックセンセイ・ブログ・サンプル・プロジェクトで採用されたアプローチです。

• https://github.com/SecureCodeWarrior/sensei-blog-examples

.sensei フォルダーには、すべてのレシピが記載されたクックブックが含まれており、リポジトリをクローンするユーザーなら誰でも使用できます。

クックブックを任意のフォルダに保存

チームは、中央の場所に保存されているクックブックを使用することもできます。

クックブックを共有書き込み権限のあるフォルダに保存すると、チーム全員がレシピを更新したり、作業中のプロジェクトにインポートしたりできます。

場所はディレクトリパスに設定されます。

レシピを Github に保存する

Senseiは、Githubリポジトリに保存されているレシピにもアクセスできます。プライベートリポジトリとパブリックリポジトリの両方がサポートされています。

SSH 経由の Github

SSH リポジトリへのアクセスは、ロケーションの次の構文を使用して設定されます

git@GitHub.com: SecureCodeWarrior/a Cookbook.git

これを機能させるには、リポジトリにクックブックフォルダーの内容が含まれている必要があります。

また、クックブックのブランチとサブフォルダー（例：マスターブランチ、クックブックサブフォルダー）を設定することもできます。

例:

• git@GitHub.com: SecureCodeWarrior/sensei-Blog-examples.git|master|.sensei

プライベートリポジトリには SSH キーを設定する必要があります。

• https://github.com/settings/keys

また、キーにはパスフレーズを含めないでください。

HTTPS 経由の Github

HTTPS 経由でパブリックリポジトリにアクセスすることも可能で、同じ repo.git|branch|folder 構文が使用されています。例:

ブログサンプルプロジェクトの場合:

• https://github.com/SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

Basic Protection のサンプルセットでは、ブランチとサブフォルダーは無視してかまいません。デフォルトで master ブランチが取得され、`rules.sensei` ファイルはルートフォルダーにあるからです。:

• https://github.com/SecureCodeWarrior/cookbook-basic-protection-set

HTTP (s) 経由で圧縮

先生は、圧縮されたクックブックにHTTPまたはHTTPS経由でアクセスすることもできます。

たとえば、HTTPサーバーがポート8000でローカルでリッスンしている場合

• http://localhost:8000/rules.sensei.zip

zip クックブックファイルには、rules.sensei ファイルなどのクックブックフォルダーの内容が含まれている必要があります。

共有概要

Senseiは、個々のプログラマーが自分の学習と生産性をサポートするレシピを作成できるように、複数のクックブックの使用をサポートしています。

さらに重要なのは、知識が共有されるときにチームが最も効果的に機能することがわかっていることです。特定のプロジェクトや特定のライブラリ、または一連の移行パターンを共有するチームリポジトリを共有することは、チームの生産性を高め、チームの経験を体系化するのに役立ちます。

クックブックを共有すると、複数のチームが同じクックブックを使用できます。これにより、AppSecなどのさまざまな分野のチーム間のコラボレーションが改善され、開発にもつながります。

Senseiには、4つのコア共有メカニズムが用意されているので、知識共有に関するコラボレーションを増やすために使用できるアプローチが少なくとも1つあることを願っています。

---

「環境設定\ プラグイン」(Mac) または「設定\ プラグイン」(Windows) を使用してIntelliJ内からSenseiをインストールし、「senseiセキュアコード」を検索するだけです。

Senseiのブログ投稿コードとレシピはすべて、Githubの次の場所にあります。

•  https://github.com/SecureCodeWarrior/sensei-blog-examples