Insights sur le code sécurisé

セキュリティ業界の多くの人々と同様に、私と数人の同僚は3月にセキュリティ業界への旅に出ました RSA カンファレンス サンフランシスコで。一年でとても忙しい時期ですが、本当に私のお気に入りのイベントのひとつです。私が特に楽しみにしているのは、Bugcrowdのイベントです。 メイヘム・アット・ザ・ミント長い会議の日々を過ごした後は、仲間や友人とリラックスして楽しい時間を過ごすチャンスです。

しかし、今年は少し違いました。私たちは個人的に祝うべきことがたくさんありました。イベントのスポンサーとして、私たちは夜に自分たちでカクテルを飲みました（もちろんセキュア・コード・サングリア）が、パーティーをやりたくなったのは、私たちとの新しいパートナーシップでした。 バグクラウド。公式発表です。私たちは、セキュアコーディングに関する開発者の教育、能力強化、啓発のために力を合わせています。

この発表、特に記事とポッドキャストのエピソードについて、幅広い業界から熱意が表明されたことを楽しみ、感謝しました アイッツ・ピー・マガジン。編集者のショーン・マーティンは、Bugcrowdのケーシー・エリスとジェイソン・ハディックスに話を聞いて、私たちがやっていることの本質を真に捉えました。それは、有意義な変化には大勢の人が関わるからです。Bugcrowdは長い間このことを認識してきました。世界中のソフトウェアエンジニアをセキュリティのスーパーヒーローに変えるために協力することは、夢の実現です。

20年以上にわたり、世界に大混乱をもたらしてきた問題の発見、脆弱性の発見、修正を行ってきた結果、セキュリティに関する議論を変えなければならないことがこれまで以上に明らかになりました。「ハッカーは必ずしも悪者ではありません。ハッカーに内在するスキルはソフトウェア強化プロセスにおいて非常に貴重であり、私たちは協力して取り組む必要があります。 左から開始。いつか試すような斬新なコンセプトではなく、ソフトウェア開発ライフサイクルの中核となるはずです。そのために、私たちとBugcrowdは、セキュリティについて多くの開発者が抱いている認識を変えることに全力を注いでいます。セキュリティは機能や機能を構築するうえで不便だという認識です。

これまでのセキュリティトレーニングは不十分でした。あまりにも頻度が低く、日常のコーディング活動とは無関係だったり、単に開発者の心をつかまなかったりすることが多いです。Secure Code Warriorは、それを変えようとしています。セキュアコーディングについて学ぶことは楽しいものです。Bugcrowdのサポートがあれば、このメッセージは私たちがとても大切にし、奨励しようとしているコミュニティに広く広めることができます。

最終的には、ソフトウェアセキュリティがソフトウェア品質の代名詞となる段階に到達する必要があります。最近では、そうではないと示唆するにはあまりにも多くの問題があります。そして、このパートナーシップにより、開発者は安全な開発に本当にワクワクできると思います。セキュリティ意識の高揚した環境とポジティブな文化が鍵であり、それを実現するのにこれほど完璧な企業は他にありません。

このスペースに注目してください。セキュリティに関する話題は今、劇的に左にシフトしつつあります。

Le cryptage de l'appareil est le processus de cryptage de toutes les données sur l'appareil Android. Une fois le cryptage activé pour un appareil Android, toutes les données créées par l'utilisateur sont immédiatement cryptées avant d'être écrites sur le support de stockage. Les données sont ainsi protégées et même si une personne non autorisée tente d'y accéder, elle ne pourra pas les lire. Cette fonction est particulièrement intéressante pour les smartphones, car ils sont transportés par l'utilisateur et sont plus susceptibles d'être perdus ou volés que d'autres appareils informatiques. Tout curieux ou voleur ne peut accéder aux données que s'il peut déverrouiller le téléphone.

Android propose deux types de cryptage : le cryptage du disque complet et le cryptage des fichiers.

Cryptage de l'intégralité du disque

Le chiffrement intégral des disques a été introduit au niveau 19 de l'API (Android 4.4 KitKat), mais les nouvelles fonctionnalités du niveau 21 de l'API (Android 5.0 Lollipop) ont réellement donné le coup d'envoi à son utilisation. Le chiffrement intégral du disque utilise une clé unique pour protéger l'ensemble de la partition des données utilisateur de l'appareil. La clé est protégée par les informations d'identification de l'utilisateur, qui doivent être fournies au démarrage de l'appareil avant qu'une partie du disque ne soit accessible.

C'est une bonne chose pour la sécurité, mais cela signifie aussi que la plupart des fonctionnalités de l'appareil sont indisponibles tant que l'utilisateur n'a pas saisi ses informations d'identification. Cela signifie que lorsque l'appareil est redémarré mais non déverrouillé, certaines fonctions comme les alarmes ne peuvent pas fonctionner, les services sont indisponibles et les téléphones ne peuvent pas recevoir d'appels. C'est pour cette raison que le deuxième mode de cryptage a été créé.

Cryptage basé sur les fichiers

Le chiffrement basé sur les fichiers, le deuxième mode de chiffrement des appareils, est disponible depuis le niveau API 24 (Android 7.0 Nougat). Dans ce mode, différents fichiers sont chiffrés avec différentes clés qui peuvent être déverrouillées indépendamment. Avec ce mode de chiffrement est apparu le mode Direct Boot, qui permet aux appareils chiffrés de démarrer directement sur l'écran de verrouillage, en activant les fonctionnalités précédemment manquantes avant de déverrouiller l'appareil.

Le démarrage direct permet aux applications de fonctionner dans un contexte limité avant que l'appareil ne soit déverrouillé. Elles peuvent ainsi continuer à fonctionner comme prévu sans compromettre les informations de l'utilisateur. Afin de fournir cette fonctionnalité, l'appareil Android a besoin de deux emplacements de stockage :

1. Stockage crypté des informations d'identification. Emplacement de stockage par défaut, disponible uniquement lorsque l'utilisateur a déverrouillé l'appareil.
2. Stockage crypté de l'appareil. Disponible en mode d'amorçage direct et après que l'utilisateur a déverrouillé l'appareil.

Si votre application doit accéder à des données lorsqu'elle est exécutée en mode d'amorçage direct, elle doit utiliser le stockage crypté de l'appareil. Mais attention aux implications en termes de sécurité ! Le stockage crypté ne doit pas être utilisé pour stocker des données sensibles ! Le stockage crypté est crypté à l'aide d'une clé qui est disponible dès que l'appareil a démarré avec succès. Toutes les données qui ne doivent être accessibles qu'à l'utilisateur doivent être sauvegardées dans l'emplacement par défaut, le stockage crypté des informations d'identification (Credential Encrypted).

Si vous souhaitez en savoir plus sur ce qu'est le cryptage ou pourquoi il est important, consultez la vidéo sur le portail Secure Code Warrior . Vous pouvez également tester vos connaissances sur le cryptage en relevant quelques défis.

Vous avez besoin d'un guide étape par étape pour votre appareil ? Consultez cet article de Bill Hess sur Pixel Privacy.

J'espère que vous avez appris quelque chose de nouveau. A la semaine prochaine !

Stockage crypté des informations d'identification, qui est l'emplacement de stockage par défaut et qui n'est disponible qu'une fois que l'utilisateur a déverrouillé l'appareil.

https://developer.android.com/training/articles/direct-boot.html

新しい研究により、質の高いセキュリティトレーニングの利点が調査されています。

質の高い安全なコードトレーニングが組織に与える潜在的な影響はどのようなものですか？また、投資する価値はありますか？答えを見つけるために、Secure Code WarriorがEvans Data Corp*と共同で実施した、安全なコーディング、安全なコードプラクティス、およびセキュリティ運用に対する開発者の態度に関する最近の調査から得られた洞察を見てみましょう。
‍

開発者とそのマネージャーに、トレーニングによってコーディング方法がどのように変わったかを尋ねたところ、各コホートの回答は少しずつ異なりました。これらの違いは、それぞれの仕事への取り組み方やソフトウェア開発ライフサイクルにおける役割と一致していました。しかし全体的に見ると、その根底にあるテーマは、質の高い安全なコードトレーニングがもたらす影響は圧倒的にプラスであるということです。

開発者の 55% は、適切なトレーニングによってコーディング手法に対する自信が高まったと回答し、53% は、優れたトレーニングによって自分のコードのデバッグやテストをより慎重に行えるようになったと回答しました。

最も重要なのは、53% が、コードを書く際にセキュリティにもっと気を配るようになり、脆弱性が減り、やり直しが減ったと考えていることです。

より迅速なソフトウェアリリースを達成しているマネージャー

マネージャーの 43% は、セキュアコードトレーニングによって組織のコードのデバッグやテストがより慎重になったと回答していますが、上位 2 つの変更は管理者の責任を反映しています。47% は、優れたトレーニングにより、セキュリティを強化するツールをより選択的に選択できるようになったと回答しています。一方、44% は、セキュアコードのトレーニングとテクニックが時間の節約とソフトウェアリリースのスピードアップに役立ったと回答しています。

セキュア・コーディングが生産性に与える影響

生産性の向上に関しては、安全なコーディング手法が大きな効果をもたらす可能性があります。安全なコーディングが生産性の向上にどのように役立つかを尋ねたところ、63% 以上の開発者が、安全かつ高品質なコードを書くことで脆弱性の再発を防ぎ、やり直しを減らすことができると回答しました。70% の開発者は、質の高いトレーニングによって、後で修正やパッチの原因となるエラーを排除できると答えています。

セキュアコーディングが開発ライフサイクルに与える影響

開発者とそのマネージャーが開発ライフサイクルに安全なコーディング手法を組み込むことで、トレーニングの実際の影響を測定できます。

SDLCの開始からすぐに生産性が向上し、改善が全面的に進んでいるようです。調査対象となった開発者の半数以上が、適切なトレーニングによってアプリケーションの設計、コーディング、デバッグとテストの生産性が向上したと回答しています。

最も影響を受けるのはデバッグとテストの段階で、開発者の 56% がこれらの活動によって生産性が向上したと答えています。より優れたスキャンツールやテストツールによってこの開発段階は短縮されたかもしれませんが、安全なコーディング手法によって、コードの脆弱性がないことが証明された検証済みコードの使用と再利用、およびセキュリティを重視したアプリケーション設計アプローチが促進されます。セキュリティへのアプローチを開発ライフサイクルの「左から」始めることで、開発者はデバッグフェーズの時間を節約できます。

開発者の 44% は、デプロイ中でも生産性が向上したと回答していますが、さらに下流にあるデプロイメントによる影響は少ないです。これは、安全なコーディング手法によってリリース速度が向上した結果です。

より良いトレーニングへの実証済みの道

質の高い安全なコードトレーニングが多くのメリットをもたらすことは間違いありません。問題は、セキュア・コード・トレーニングの質をどのように判断するかということです。

その答えを見つけるために、開発者に何が欲しいかを尋ねました。開発者の 75% は、体系的な実地研修を希望していました。彼らは、理論に基づいた静的学習という骨の折れる作業よりも、実践による学習方法を好んでいます。脆弱性の阻止に関しては、開発者は最前線にいます。そのため、現在のほとんどのトレーニングプログラムには欠けている実践的なアプリケーションに焦点を当てたトレーニングを求めています。

Secure Code Warriorは、セキュアコーディングにおける変革の推進者として、人間が主導する防御策の構築を支援するために、人間主導のアプローチを採用しています。当社の実績ある学習プラットフォームは、状況に応じたハンズオントレーニングコンテンツをさまざまな場面で提供します。 50以上の言語:フレームワーク開発者が現実の世界で直面している課題を模倣した課題があります。これらはすべて、明日のニュースになる前に脆弱性を防ぐことで、リリースまでのコストと時間を削減します。

チームへの潜在的な影響と、安全なコードをより迅速に提供する能力を確認したい場合は、今すぐデモを予約してください。

Lorsqu'elles sont développées pour la téléphonie mobile, les applications doivent souvent demander des autorisations au système. Elles peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou à la possibilité d'envoyer des messages SMS. Toutes les permissions mentionnées ci-dessus sont des permissions de plateforme, définies par le cadre Android.

Mais dans certains cas, ces autorisations ne suffisent pas et l'application doit définir ses propres autorisations personnalisées. Prenons l'exemple de notre propre entreprise. Secure Code Warrior pourrait créer une application qui enregistre certaines données privées dans le cadre d'un profil, y compris les performances de l'utilisateur sur la plateforme SCW. Nous aimerions permettre à une autre application de formation à la sécurité, par exemple DevTrainer, d'utiliser ces données si l'utilisateur lui en donne l'autorisation. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les connaisse, mais l'application SCW ne devrait pas complètement les cacher et les protéger car elles pourraient être utiles. Nous souhaitons donc permettre à l'utilisateur d'exercer un contrôle sur ces données. C'est là qu'interviennent les autorisations personnalisées.

Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il veut l'autoriser ou non. Il s'agit d'une pratique courante et d'un bon moyen de restreindre l'accès aux applications figurant sur la liste blanche.

Malheureusement, les permissions personnalisées présentent certains comportements non intuitifs qui les rendent risquées du point de vue de la sécurité. Concrètement, les autorisations personnalisées peuvent être définies par n'importe quelle application à n'importe quel moment, et "le premier qui gagne", ce qui n'est pas sans conséquences.

Pour le scénario suivant, nous définissons deux profils d'applications que nous avons introduits ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :

1. SCWApp: l'application qui définit une permission personnalisée et défend un composant utilisant cette permission.

2. DevTrainer: cette application définit la même permission que SCWApp et déclare à l'utilisateur qu'elle souhaite détenir cette permission.

Il s'agit d'un scénario courant, appelé "Peer Apps Case" (cas des applications homologues). Si l'application DevTrainer n'était qu'un plugin pour SCWApp, elle n'aurait pas à définir de permission personnalisée. L'hypothèse, dans ce cas, est que SCWApp sera installée avant DevTrainer et qu'aucun comportement inattendu ne se produira. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite SCWApp, la permission n'est pas accordée rétroactivement à DevTrainer, de sorte que les tentatives d'utilisation du composant sécurisé par l'application DevTrainer échoueront.

C'est là qu'intervient le cas de l'application Peers. Dans certains cas, vous ne pouvez pas vous attendre à ce qu'une application soit installée avant l'autre. Par exemple, si Facebook et Twitter veulent tous deux utiliser les composants de l'autre, ils doivent définir les autorisations personnalisées de l'un et de l'autre.

Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.

La situation est encore plus délicate. L'application DevTrainer peut modifier le niveau de protection des autorisations. Android n'utilise pas le niveau de protection du défenseur, mais le niveau de protection défini en premier, ce qui signifie que l'application installée en premier peut le définir. Cela signifie que si DevTrainer modifie le niveau de protection des permissions pour qu'il devienne normal, toutes les applications futures qui demanderont cette permission n'auront pas à être confirmées par l'utilisateur, mais se verront automatiquement accorder l'accès.

Ce scénario a été inspiré par l'explication de ce problème trouvée sur le github de cwac-security.

La stratégie du "premier qui gagne" a des conséquences dangereuses et la méconnaissance de son comportement peut conduire le développeur à prendre des décisions de sécurité basées sur des données non fiables et à permettre à des applications non souhaitées d'accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter les décisions de sécurité basées sur des données non fiables, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais comme actuellement, plus de 22% des appareils Android utilisent encore une version inférieure d'Android, il est important d'atténuer les risques du comportement original dans votre application. Vérifiez si la permission a déjà été définie lors de la première exécution de votre application et prenez les mesures appropriées si c'est le cas pour résoudre les risques de sécurité.

Bonne chance pour le codage et à la semaine prochaine !

En définissant des autorisations personnalisées, une application peut partager ses ressources et ses capacités avec d'autres applications.

https://developer.android.com/guide/topics/permissions/defining.html

2018 年 1 月 27 日。セキュア・コード・ウォリアーの誕生日は、オーストラリア・デーの1日後です。今年も素晴らしい一年を思い浮かべているうちに、私の人生には3歳児が2人いて、1人はビジネスと1人の人間がいることに気付きました... 驚くべき類似点があります。

• きちんとしたルーチンがないと、夕方に寝るのが面倒です。

「届いたばかりの最後のメールを読んでいるだけ... それとも待って、すぐに米国のチームと電話で同期する必要があります... さもないと、この提案書は今夜までに提出する必要があります。くそー。また真夜中過ぎだ。」

• 彼らが何かを成し遂げたとき、彼らはあなたをとても誇りに思うでしょう

たとえ3週間ぐっすり眠れなかったり、運動する時間がなかったり、散らかったものを片付けなければならなかったりしたとしても... しかし、パイロット試験で開発者のセキュリティスキルへの影響が実証され、お客様は喜んでさらに3年間私たちと一緒に働くことを約束してくれました！ブーム！エネルギーピーク。そして、いたるところにケーキ。突然、睡眠不足はそれほど気にならなくなりました。

• 彼らはとても早く成長します

チームと一緒にバリ島にこっそり出て、ビーチハウスでプラットフォームの次の機能に取り組むことができた時代は終わりました。シドニー（AU）とブルージュ（BE）でエンジニアリングを行い、米国、ヨーロッパ、オーストラリアで営業とマーケティングを行い、当社のスタートアップ企業は昨年、4～6倍に成長しました（スタッフ、顧客、または収益を測定するかどうかによって異なります）。1年前、オーストラリアの大手銀行の1つを顧客として迎えることができて本当にワクワクしたときのことを覚えています。現在、私たちは世界の金融機関トップ100社のうち10社と、次世代のオンラインサービスを構築している主要な通信会社やテクノロジー企業と協力しています（注：最初の顧客であったオーストラリアの銀行を今でも本当に誇りに思っています！）。

私たちは多くの面で急速に成長してきましたが、昨年の重要なマイルストーンの1つは、実際に会社のビジョンを定義したことでした。創業当初、私たちはキャッシュの構築、実行、確保に重点を置いていたため、立ち止まって達成したいことを正確に振り返ることを忘れがちでした。Secure Code Warriorに参加する人が増え、参加する顧客が増えるほど、一貫したビジョンを持ち、私たちがどこに向かっているのかを理解することがより重要になりました。私たちは2017年にそれを実現しました。

もう1つの重要なマイルストーンはテクノロジー関連でした。私たちは早い段階で、開発者のスキルを身につけることは安全なコーディングの旅の始まりに過ぎないことに気付きました。彼らには、後から考えたり、コードを書いたときに思い浮かぶようなものではなく、セキュリティを組み込んで簡単にするためのツールが必要です。いいえ、セキュリティはコードを書きながら最初から構築する必要があります。

私たちのチームは、開発者がより安全なコードを書くのに役立つ最も一般的な IDE (IntelliJ、Visual Studio、Android Studio など) 用のセキュリティコーチングプラグインの作成に懸命に取り組んできました。潜在的なセキュリティ上の弱点を指摘するだけではなく、開発者がセキュリティの主要なプラクティスと合致しないコードを書いているときには、コーチになってすぐに参加できるように努めています。セキュリティコーチングプラグインは Sensei と呼ばれ、開発者がその場でトレーニング (マイクロラーニング) を受けることを可能にし、場合によっては、コードを即座に修正するための自動修正オプションも提供します。

これからの12か月がどうなるのか、本当にワクワクしています。ソフトウェア・セキュリティは、もはや、銀行、通信会社、テクノロジー企業などの開発者中心の大企業だけの関心事ではないことが分かってきました。あらゆる種類の組織がソフトウェアの弱点によって危険にさらされ続けており、SQL インジェクションは最終的には死滅するかもしれませんが、その代わりを待っている組織は他にもたくさんあります。

現在、あらゆる業界の顧客、市場、取締役会から、企業がコードのセキュリティを保護することへの期待が高まっています。コンプライアンスは組織をこの方向に押し進め続けるでしょう (例:ヨーロッパでビジネスを行うすべての人が対象とするGDPR、オーストラリアで導入されるデータ漏えい法など

つまり、SCWプラットフォームは、世界中で、そして新しい業界でも急速な成長を続けると確信しています。これはもちろん私たちのビジネスにとっては朗報ですが、私のチームがビジョンを実現するのにも役立ちます。私たちが住んでいるソフトウェア時代にとって、それは非常に価値のあることだと私は信じています。

当社のツールを使用する開発者は、自社のセキュリティにおいてより積極的な役割を果たすことができますし、現在もそうしています。彼らには安全なコードを書き、会社の最前線となるためのスキルとツールがあります。

Secure Code WarriorのCEOであり、3歳児の親であることについても同じように感じています。毎年が前回よりも良くなっています。4歳児がどのように成長していくのか楽しみです！

私たちのビジョンは、セキュリティの可視性を高め、最初から安全なコードを書くためのスキルとツールを提供することで、開発者が組織の最前線に立つことができるようにすることです。

開発者がいる場所で会いましょう

より迅速で安全なリリースのためにDevSecOpsを検討している組織は、統合されたテクノロジースタックによって開発者の生産性を最適化することの重要性を知っています。Secure Code Warriorのソフトウェア統合は、GitHub、Jira などの日常的に使用するツールに統合された安全な開発リソースを開発者に提供します。

Secure Code Warriorを使用すると、安全なコードプログラムをお好みの製品や開発者のワークフローに直接組み込むことができるため、ジャストインタイムの修正が可能になり、学習成果も安定します。

迅速な修復による脆弱性の軽減

脆弱性を見つけて修正することは、いくつかのピースや役立つカバーアートなしで大きなパズルを解くようなものです。堅牢なソリューションが完成するまでに数日、数週間、場合によっては数か月かかることもあります。これは、開発者が問題の修正方法を知らない場合や、これまで問題に遭遇したことがない場合や、テストも検証もされていないソリューションの展開をためらっている場合など、特に難しい場合があります。

EdgeScan 2022脆弱性統計レポートによると、フルスタック全体で見つかった脆弱性の平均修復時間（MTTR）は 57.5 日 (エッジスキャン 2022 脆弱性統計レポート)。

これは、貴重なデータが危険にさらされ、信頼が失われ、貴重な開発者の生産性が無駄になる重大な状況です。その結果、コードリリースの速度が低下し、デプロイされたソリューションに関する知識や信頼の欠如による迅速な修正やずさんなパッチワークにより、最終的には技術的な負債が増えます。

Secure Code Warriorのインテグレーションは信頼できる修復アドバイスを提供するため、開発者はフロー内にとどまりながらセキュリティバグを自信を持って解決できます。開発者が自分で修正を行えるようにすることで、AppSecはリスクの監視と組織のセキュリティ体制の強化に集中できます。

作業項目にコンテキストに応じたセキュア・コーディング・ガイダンスを組み込むことで、開発者は検出された脆弱性とその修正方法について詳しく学ぶための支援を即座に得ることができます。その結果、MTTRが短縮されるだけでなく、ソースの脆弱性を積極的に減らす貴重な学習結果、つまりコードの脆弱性を積極的に削減できるだけでなく、MTTRが短縮されます。

チーム全体で学習をスケールアップ

SCORM LMS インテグレーション

SCORMは共有可能なコンテンツオブジェクト参照モデルを意味し、eコースの国際標準です。コースがSCORM形式で公開されていれば、ほとんどすべての学習管理システム (LMS) で認識されるはずです。SCORMを使えば、簡単に管理できます。 セキュアコードトレーニング 他のトレーニングプラットフォームと一緒に1か所でプログラムできます。

コードを発送する前に、習熟度を確認してください

Okta ワークフロー向けセキュアコードウォリアーコネクター フローに組み込むことができるセキュリティ能力チェックの機能により、安全でないコードがコードベースに導入されるのを防ぐのに役立ちます。GitHub リポジトリなどのコードベースで作業する場合、必要なレッスンや評価をベースのコーディングの修飾子として設定できます。これにより、リーダーは各開発者が関連するコードベースで作業する準備が整っていることを確認できるようになり、組織全体のセキュリティ体制をレベルアップできます。

個々の開発者がリポジトリにアクセスしてコードをコミットするために必要なセキュア・コーディング・スキルを習得していることを確認することで、ソフトウェア開発ライフサイクル全体にセキュリティを導入します。この統合により、開発者はSCWの非常に魅力的なプラットフォームを通じて最新のセキュリティプラクティスを確実に学び、手動によるコードレビューの負担の一部が軽減され、エンジニアリング時間を解放して品質を犠牲にすることなくより多くの機能をリリースできるようになります。

Okta + SCW について詳しくはこちらまたはを参照してください デモ ここ。

コードをコミットする際のジャストインタイムサポート

SCW for GitHub により、GitHub ワークフロー内でのコンテキストトレーニングが可能になります SARIF ファイルに保存するか、作業中のイシューやプルリクエストに直接保存してください。これにより、開発者は最も必要なときに知識にアクセスできるようになり、高品質なコードをより早くリリースできるようになります。この統合によって、理解せずに適用されることが多いパッチが可能になるだけではありません。脆弱なコードを迅速に認識できるように、適切で安全なコーディングパターンが継続的に強化されます。

SCW+GitHub についてさらに詳しくまたはを参照してください デモ

GitLab に統合された、実用的で安全なコーディングガイダンス 脆弱性レポートの脆弱性の詳細セクションに関連性の高いSecure Code Warriorトレーニングリンクが埋め込まれています。この統合を可能にすることで、最終的に知識の学習と応用の間の時間差を縮め、将来利用できるようにするのに役立ちます。たとえば、脆弱性スキャナーがアプリケーションコード内のクロスサイトリクエストフォージェリ (CSRF) を検出した場合、脆弱性の詳細が関連するトレーニングリンクで更新されます。

「Secure Code Warriorのプラットフォームにおけるセキュアコーディングの広範なコンテキスト学習を提供することで、開発者は最初からセキュリティファーストを採用できるようになり、時間を節約できるだけでなく、新しいスキルの開発にも役立ちます。」-GitLabの副社長、Nima Badiey

さらに詳しく SCW + GitLab について

シノプシス・シーカーの統合 Secure Code Warriorのリソース、ビデオ、およびSeeker内の脆弱性発見へのトレーニングリンクが埋め込まれています。これにより、Seeker内の簡単にアクセスできるトレーニングガイダンスで脆弱性を特定して解決するマイクロラーニングにより、業界標準や規制への準拠が保証されます。

シノプシス + SCW の詳細はこちら

今すぐ必要なときにチケット内のヘルプ

セキュリティ上の欠陥を見つけるだけじゃなくて、修正の手助けを求めてください Jira 用セキュアコードウォリアー。 開発者は Jira Issue Tracker 内で状況に応じたトレーニングを受けることができるため、開発者は最も必要なときに知識にアクセスできるため、高品質なコードをより早くリリースできます。Secure Code Warrior for Jira はこれらの問題の詳細を検出し、開発者が慣れ親しんだ環境内の特定のトレーニングビデオにアクセスすることで、これらの問題の解決方法を学ぶ機会を開発者に提供します。コンテキストに応じたマイクロラーニングを通じて、開発チームはコードベース全体の脆弱性を減らし、Jira を介して追跡と報告することで脆弱性を常に把握できます。

さらに詳しく SCW + Jira について

安全なコードを高速に作成

Secure Code Warriorの技術スタック統合により、一般的な脆弱性に対する業界で信頼されているガイダンスとソリューションによるマイクロラーニングと迅速な修復が可能になります。

• トレーニングリンクは Issue やプルリクエストにコメントとして添付されるため、必要なときに簡単にガイダンスにアクセスできます。

• コンテンツは関連性が高く、共通弱点列挙（CWE）またはオープンウェブアプリケーションセキュリティプロジェクト（OWASP）の参照に基づいて取得されます。

• 対象範囲が広いということは、学習リソースは世界有数の安全なコーディングトレーニングのコレクションから提供されているということです。

よくある脆弱性は、その多くが数十年前から知られていますが、事後対応型の対策により、SDLC内で未だに存在し続けています。スキャンツールとペンテストで問題が発見されるのは、多くの場合、アプリケーションがすでに本番環境に入った後です。これらのツールは非常に遅いことで有名で、複数の誤検出や陰性が見つかり、手動での確認が必要になり、問題の原因や原因に対処することはほとんどありません。

開発者がワークフロー内でマイクロラーニングと修復アドバイスを提供できるようにすることで、開発者は開発プロセスの早い段階でセキュリティの弱点を発見でき、さらに悪いことに、後で悪用される可能性のある脆弱性を残す前に開発プロセスの早い段階で発見できます。Secure Code Warriorインテグレーションは、開発者が作業する場面に対応し、脆弱性の発見と修正を迅速に行えるようにするだけでなく、信頼できるリソースと簡単なガイダンスから学び、ソフトウェア開発ライフサイクルの重要な要素としてスキルを高め、セキュリティを強化します。

もっと詳しく知りたいですか？

• プロダクトトークのウェビナーを視聴して、SCWのエキサイティングなインテグレーションについて学びましょう
• Okta のデモをチェック
• GitHub のデモを視聴する
• セキュア・コード・ウォリアーを無料でお試しください

この記事のバージョンが掲載されました サイバーセキュリティインサイダー. ここで更新され、シンジケートされました。

‍

大規模言語モデル（LLM）コード作成者から高度なエージェントAIエージェントに至るまで、人工知能アシスタントの採用は、ソフトウェア開発者に豊富なメリットをもたらします。しかし、MITの新しい調査で明らかになった最近の発見は、「AIへの依存度が高すぎると、ユーザーは批判的思考能力を失う可能性がある」という警告を発しています。

AIの導入に伴ってAI関連のセキュリティリスクが高まっているソフトウェア環境を考えると、この認知機能の低下は確かに壊滅的な結果につながる可能性があります。開発者や組織にとって、ソフトウェア開発ライフサイクル (SDLC) の早い段階でセキュリティの脆弱性を積極的に特定、理解、軽減することは倫理的に不可欠です。今日の多くの組織で言えることですが、この義務を怠ると、潜在的なセキュリティ脅威も同様に急激に増加しています。その中には AI に直接起因するものもあります。

生産性と効率性のメリットは無視できないため、議論の的になっているのはAIを使用するかどうかではありません。むしろ、本当の問題は、いかにしてAIを最も効果的に適用するか、つまり、生産量の増加を最大化しながら安全保障を守ることだ。そのためには、コードの出所を問わず、コードを深く理解している、セキュリティに精通した開発者が行うのが一番です。

AIへの過度の依存は認知機能の低下を招く

ザの MITのメディアラボによる調査6月上旬に公開され、ボストン地域の5つの大学の54人の学生がエッセイを書いている間に認知機能をテストしました。学生は、大規模言語モデル (LLM) を使用するグループ、検索エンジンを使用するグループ、外部からの支援を受けずにオールドスクールに通う学生の3つのグループに分けられました。研究チームは脳波記録（EEG）を用いて参加者の脳活動を記録し、認知的関与と認知的負荷を評価しました。研究チームは、昔ながらの「脳のみ」のグループが最も強力で最も広範囲の神経活動を示したのに対し、検索エンジンを使用するグループは中程度の活動を示し、LLM（この場合はOpenAIのChatGPT-4）を使用するグループが最も少ないことを発見しました。

これは特に驚くべきことではないかもしれません。結局のところ、思考を代行してくれるツールを使用すると、考えることが少なくなります。しかし、この調査では、LLMユーザーは論文とのつながりが弱いことも明らかになりました。83% の学生は、修了後わずか数分でエッセイの内容を思い出すのに苦労し、参加者の誰も正確な引用をすることができませんでした。他のグループと比べると、著者の当事者意識が欠けていました。脳のみの参加者は、当事者意識が最も高く、最も幅広い脳活動を示しただけでなく、最も独創的な論文も作成しました。LLMグループの結果はより均質的で、実際、審査員はAIの成果と容易に判断できました。

開発者の観点から見ると、主な結果はAIの使用に起因する批判的思考の低下です。もちろん、AI に頼る例が 1 回あっても、本質的な思考スキルが失われることはないかもしれませんが、時間をかけて使い続けると、そうしたスキルが萎縮する可能性があります。この調査は、ユーザーがAIを助けるのではなく、AIがユーザーを助けることで、批判的思考をAIを使い続けさせる方法を提案しています。しかし、真の重点は、開発者が安全なソフトウェアを構築するために必要なセキュリティスキルを身に付け、それらのスキルを日常的で不可欠な仕事の一部として使用できるようにすることです。

開発者教育:AI 主導のエコシステムに不可欠

MITのような調査でも、あらゆる分野で進められているAIの採用が止まることはありません。スタンフォード大学の 2025 人工知能インデックスレポート その結果、2024年には78％の組織がAIの使用を報告しましたが、2023年には55％でした。このような成長は今後も続くと予想されます。しかし、利用の増加はリスクの増大にも反映されています。レポートによると、AI 関連のサイバーセキュリティインシデントは同時期に 56% 増加しています。

スタンフォード大学の報告書は、以下のことが極めて重要であることを強調しています AI ガバナンスの向上また、組織がセキュリティ保護措置を実施するのが緩いことも判明したためです。事実上すべての組織がAIのリスクを認識していますが、AIに対して何かをしている組織は3分の2未満であり、多くのサイバーセキュリティの脅威に対して脆弱であり、ますます厳しくなる規制遵守要件に違反する可能性があります。

答えがAIの使用をやめることではなく（誰もやらないでしょう）、AIをより安全かつ確実に使用することです。MITの調査は、その方法について役立つ手がかりを1つ提供しています。この研究の4番目のセッションでは、研究者はLLMユーザーを2つのグループに分けました。1つは、ChatGPTに助けを求める前に自分でエッセイを始めたグループ（この研究では「Brain-to-LLM」グループと呼ばれる）で、もう1つは、ChatGPTに個人的な注意を払う前に最初の草稿を作成してもらったグループ（LLM-to-Brainグループと呼ばれる）です。Brain-to-LLMグループは、すでに下書きしたエッセイをAIツールを使って書き直したグループでは、検索エンジンのユーザーと同様の領域もあり、想起率と脳活動が高かった。AIによるエッセイの開始を許可したLLM-to-Brainグループでは、神経活動の協調性が低く、LLMボキャブラリーの利用に偏っていました。

ブレイン・トゥ・LLMアプローチはユーザーの頭脳を少し研ぎ澄ませるのに役立つかもしれませんが、開発者はソフトウェアを安全に記述し、AIが生成したコードのエラーやセキュリティリスクを批判的に評価するための特定の知識も必要とします。開発者は、AI に脆弱性などのセキュリティ上の欠陥がもたらされる傾向を含め、AI の限界を理解する必要があります。 プロンプト注入 攻撃。

そのためには、企業セキュリティプログラムを全面的に見直して、人間中心のSDLCを実現する必要があります。このSDLCでは、開発者が企業全体のセキュリティファースト文化の一環として、効果的で柔軟性があり、実践的かつ継続的なスキルアップを受けることができます。開発者は、急速に進化する高度な脅威、特にソフトウェア開発におけるAIの果たす重要な役割によって引き起こされた脅威に遅れずについていくために、継続的にスキルを磨く必要があります。これにより、たとえば、ますます一般的になりつつあるプロンプトインジェクション攻撃などを防ぐことができます。しかし、その保護が機能するためには、組織は安全な設計パターンと脅威モデリングに焦点を当てた開発者主導の取り組みが必要です。

結論

LLMやエージェントが面倒な作業を行うと、ユーザーは受動的な傍観者になります。この研究の著者らは、「批判的思考能力の低下、教材に対する理解の深さ、長期記憶形成の低下」につながる可能性があると述べています。認知的関与のレベルが低いと、意思決定能力が低下する可能性もある。

サイバーセキュリティに関しては、組織が批判的思考を欠くわけにはいきません。また、高度に分散されたクラウドベースの環境におけるソフトウェアの欠陥がサイバー攻撃者の最大の標的となっているため、サイバーセキュリティは、開発者、AIアシスタント、エージェントのいずれによって作成されたものであっても、安全なコードを確保することから始まります。AI が持つすべての力にもかかわらず、組織はこれまで以上に高度に磨き上げられた問題解決能力と批判的思考能力を必要としています。そして、それをAIにアウトソーシングすることはできません。

SCW Trust Agent の新しい AI 機能により、セキュリティを犠牲にすることなく SDLC での AI 導入を確実に管理するために必要な詳細なオブザーバビリティと制御が可能になります。 さらに詳しく。

Il est de plus en plus évident que les entreprises doivent intégrer les principes de la conception sécurisée dans leurs processus de développement de produits, non seulement pour des raisons de conformité, mais aussi parce qu'il s'agit d'une exigence commerciale essentielle. Ces lignes directrices permettent aux entreprises d'identifier et d'atténuer les failles exploitables dans leurs produits avant de les lancer sur le marché. Les produits construits conformément à ces principes par des organisations qui considèrent ces lignes directrices comme un pilier fondamental, plutôt que comme un simple ajout, ont tendance à rester en tête sur ce marché de plus en plus concurrentiel. 

Mais deux ans après la publication des lignes directrices Secure by Design de l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) du gouvernement des États-Unis, la mise en œuvre effective dans le monde réel reste un casse-tête pour l'ensemble du secteur. Nous savons tous que ces principes sont importants, mais comment les mettre en œuvre efficacement à grande échelle ?

Dans notre dernier livre blanc, nos cofondateurs, Pieter Danhieux et Matias Madou, Ph.D., ont rencontré plus de vingt responsables de la sécurité d'entreprise, notamment des RSSI, des responsables AppSec et des professionnels de la sécurité, afin d'identifier les principales pièces de ce puzzle et de découvrir la réalité qui se cache derrière le mouvement Secure by Design. Il s'agit d'une ambition partagée par les équipes de sécurité, mais il n'y a pas de manuel de jeu commun. 

Découvrez quelques-unes des principales conclusions :

• La plupart des praticiens de la sécurité et des chefs d'entreprise adhèrent à l'idée et à la valeur des initiatives "Secure by Design" ; toutefois, cette notion reste, d'une certaine manière, ouverte à l'interprétation, et il n'existe pas d'approche standard à l'échelle de l'industrie pour la mettre en œuvre.

• La modélisation des menaces n'est pas seulement un élément à cocher sur la liste de contrôle de la conformité - c'est une pratique essentielle et cohérente qui aide les développeurs soucieux de la sécurité et leurs homologues de l'AppSec à garder une longueur d'avance sur les risques avant qu'ils ne se transforment en exploits. 

• L'épée à double tranchant qu'est l'IA - L'IA est à la fois une percée et un risque de sécurité puissant qui élargit considérablement la surface d'attaque. Sa croissance explosive introduit des risques en évolution rapide que les développeurs non qualifiés et les équipes AppSec manquant de ressources ont souvent du mal à atténuer.

Le problème n'est pas un manque de compréhension de l'importance de l'application des principes de la conception sécurisée (Secure by Design) - au contraire, le besoin de logiciels sécurisés est devenu un besoin fondamental et une attente de base. Ce qui manque, c'est une stratégie coordonnée et évolutive pour intégrer ces principes tout au long du cycle de développement des logiciels. 

Nous semblons également manquer de repères clairs ou de résultats mesurables pour déterminer les déploiements réussis. Sans cela, les équipes ne savent pas si leurs efforts ont vraiment un impact. Pour l'instant, nous semblons avoir un front uni, mais pas de stratégie commune. 

La sécurité dès la conception est essentielle et inévitable, et pas seulement pour les secteurs où la conformité est élevée. Les développeurs doivent également être responsabilisés, et non accablés. Lorsqu'ils disposent des compétences, des outils et du soutien appropriés, ils deviennent non seulement des constructeurs, mais aussi des défenseurs, intégrant la sécurité là où elle compte le plus : à la source. 

Téléchargez maintenant et découvrez comment votre équipe peut s'appuyer sur de puissantes stratégies de gestion des risques pour les développeurs et sur des mesures précises pour mener à bien une initiative Secure by Design unifiée au sein de l'entreprise.

ソフトウェア開発者は、ジェネレーティブ人工知能 (AI) を利用してコードを書く準備ができており、進んで利用する意志があることを示しており、概ね好調な結果が得られています。しかし、危険なゲームをしている可能性があるという兆候もたくさんあります。

最近によると GitHub による調査、米国の開発者の90％以上がAIコーディングツールを使用しており、完了時間の短縮、インシデントの迅速な解決、より協調的な環境などの利点を挙げています。これは重要だと感じています。AI ツールを使うことで、開発者はルーチンタスクを引き継ぐことができるため、会社に利益をもたらす、よりクリエイティブな仕事に取り組むことができるようになり、偶然ではなく、仕事中の燃え尽き症候群の可能性が減ります。

ただし、研究により、AIツールには次のような傾向があることも示されています 欠陥を導入する コードを書くとき。A スナイクによる調査 回答者の 75.8% がAIコードは人間のコードよりも安全だと答えたものの、56.4％がAIがコーディングの問題を引き起こすことがあると認めていることがわかりました。驚くべきことに、回答者の 80% が開発中に AI コードのセキュリティポリシーを迂回していると答えています。

オープンAI以来 GPT チャット 2022年11月に登場したジェネレーティブAIモデルの使用は、他の多くの分野と同様に、金融サービスのコード開発プロセス全体に急速に普及しています。他にも次のようなモデルが急速に登場しています。 GitHub コパイロット、 オープンAIコーデックス、および 増え続けるリスト 他の人の中には、ジェネレーティブAIができることとそれがもたらす影響のほんの一部しかないという意見もあります。しかし、その影響がプラスになるためには、生成されるコードが安全であることを確認する必要があります。

コーディングのバグはすぐに広がる可能性があります

人間の開発者によって作成されたものであれ、AIモデルによって作成されたものであれ、コードは いくつかのエラーを含む。高度に分散されたクラウドベースのコンピューティング環境における増え続ける要求を満たすために、AI がコード開発を加速するのに役立っているため、不良コードが発見される前に広く伝播する可能性が高まる可能性があります。

コードを書くように訓練されたAIモデルは、さまざまなタスクを実行する何千ものコード例を取り込み、それらの例を利用して独自のコードを作成できます。しかし、処理対象のサンプルに欠陥や脆弱性が含まれている場合、それがもともと人間によって作成されたものであれ、別の人工知能によって作成されたものであれ、モデルはそれらの欠陥を新しい環境に移す可能性があります。

検討中 研究によるとわかっています AIモデルは、使用しているコードの欠陥を確実に認識できないため、欠陥や脆弱性の拡散に対する組み込みの防御策はほとんどありません。AIはコーディングのミスを犯すだけでなく、将来どこかで脆弱性が特定されるまで、おそらく自社が開発したソフトウェアを使用している企業への侵害が成功するという形で、自身や他のソースのミスを繰り返します。

コーディングの欠陥が蔓延するのを防ぐ真の防御策は、人間とAIモデルが連携することです。人間の開発者は AI コードの記述を監督し、安全でないコーディング手法や脆弱なコードに対するチェックの役割を果たすべきです。しかし、そのためには、開発者がAIが犯す可能性のあるコーディングミスを特定して迅速に修正できるように、安全なコード作成のベストプラクティスについて徹底したトレーニングを受ける必要があります。

AI コードの作成と修正の課題

ChatGPTのような大規模言語モデル (LLM) が突然爆発的に増加したことは、諸刃の剣のようなものでした。一方では、時間と手間がかかる、または困難な雑用を AI を使って処理することで、企業や日常ユーザーの生産性が大幅に向上しました。一方で、AIに仕事を任せようとやみくもに信頼した場合に、何がうまくいかないかの例はたくさんあります。

AIモデルが作った 明白な間違い、バイアスを示して制作した 完全な幻覚。多くの場合、問題の根源は不十分または無責任なトレーニングデータでした。どのAIモデルも、そのトレーニングに使用したデータによって品質が決まるため、トレーニングデータは包括的で慎重に吟味されていることが不可欠です。ただし、それでもいくつかの間違いは犯されます。

コーディングにAIを使用することは、同じハードルの多くに直面します。AI によって生成されたコードには、クロスサイトスクリプティングやコードインジェクションに対する脆弱性や、AI や機械学習 (ML) に特有の次のような攻撃など、さまざまな欠陥が含まれていることが明らかになっています。 プロンプト注入。また、AI モデルはプロセスが透明でないためにブラックボックス内で動作し、セキュリティチームや開発チームが AI がどのように結論に達したかを見ることができません。その結果、モデルは同じミスを何度も繰り返す可能性があります。コード作成に影響する可能性があるのと同じ欠点が、AI の使用にも引き継がれます。 コード修復 そしてコンプライアンス要件を満たしています。

AIモデルによって欠陥が生み出されたり繰り返されたりする可能性が高まり、LLMが独自のオープンWebアプリケーションセキュリティプロジェクト（OWASP）リストを持つようになりました。 上位 10 件の脆弱性。

開発者とAIが協力して安全なコードを作成できます

AI で生成されたコードに潜在的な欠陥があるという懸念から、一部の組織は、一時的ではあるが、テクノロジーの導入を断念するかもしれない。しかし、特にAI開発者がモデルの革新と改善を続けている中で、その潜在的なメリットは無視できないほど大きいです。たとえば、金融サービス業界は、この魔力を取り戻す可能性は低いでしょう。銀行や金融サービス企業はすでにテクノロジー主導型になっており、常に競争上の優位性を求めている分野で事業を展開しています。

重要なのは、リスクを最小限に抑える方法でAIモデルを実装することです。つまり、セキュリティを意識し、安全なコーディングのベストプラクティスについて十分なトレーニングを受けた開発者がいるということです。そうすれば、開発者は安全なコードを自分で作成し、AI モデルが生成するコードを綿密に監視できます。AIエンジンと人間の開発者が緊密なパートナーシップのもとで協力し、開発者が最終決定権を持つことで、企業は生産性と効率性の向上のメリットを享受できると同時に、セキュリティの向上、リスクの軽減、コンプライアンスの確保も実現できます。

セキュア・コーディングが金融サービス企業の成功、セキュリティ、利益の確保にどのように役立つかについての包括的な概要については、新しくリリースされたSecure Code Warriorガイドをご覧ください。 金融サービスのセキュリティトレンドに関する究極のガイド。

‍

‍

Veuillez vérifier Secure Code Warrior Sur notre blog, vous pourrez approfondir vos connaissances sur la cybersécurité et les menaces de plus en plus dangereuses, et découvrir comment mieux protéger votre organisation et vos clients grâce à des technologies et des formations innovantes.

‍