Code de sécurité Insight

Comme beaucoup de personnes dans l'industrie de la sécurité, j'ai fait le voyage en mars avec plusieurs collègues pour assister à la conférence RSA à San Francisco. Bien qu'il s'agisse d'une période de l'année extrêmement chargée, c'est vraiment l'un de mes événements préférés. J'attends avec impatience le Mayhem at the Mint de Bugcrowd, qui est l'occasion de se détendre et de passer un bon moment avec ses pairs et ses amis après de longues journées de conférence.

Cette année a été un peu différente. Nous avions beaucoup de choses à célébrer personnellement. En tant que sponsors de l'événement, nous avions notre propre cocktail (Secure Code Sangria, bien sûr), mais ce qui m'a vraiment donné envie de faire la fête, c'est notre nouveau partenariat avec Bugcrowd. C'est officiel : nous unissons nos forces dans la lutte pour éduquer, responsabiliser et éclairer les développeurs sur le codage sécurisé.

J'ai apprécié l'enthousiasme exprimé par l'ensemble du secteur à l'égard de cette annonce, en particulier l'article et l'épisode de podcast d'ITSPmagazine. En s'adressant à Casey Ellis et Jason Haddix de Bugcrowd, le rédacteur en chef Sean Martin a vraiment saisi l'essence de la raison pour laquelle nous faisons ce que nous faisons : c'est parce qu'un changement significatif nécessite une foule. Bugcrowd l'a reconnu depuis longtemps, et travailler ensemble pour transformer les ingénieurs logiciels du monde entier en super-héros de la sécurité est un rêve devenu réalité.

Après plus de vingt ans passés à casser des choses, à trouver et à corriger des vulnérabilités qui ont fait des ravages dans le monde, il est devenu plus évident que jamais que la conversation autour de la sécurité doit changer. Les "hackers" ne sont pas toujours les méchants ; leurs compétences inhérentes sont inestimables dans le processus de fortification des logiciels, et nous devons faire un effort concerté pour commencer à gauche. Il ne doit pas s'agir d'un nouveau concept à essayer un jour, mais d'un élément central du cycle de vie du développement logiciel. Pour ce faire, Bugcrowd et nous-mêmes nous engageons à changer la perception qu'ont de nombreux développeurs de la sécurité, à savoir qu'elle est un obstacle gênant à la création de fonctionnalités et de caractéristiques.

Jusqu'à présent, la formation à la sécurité a été inadéquate. Beaucoup trop peu fréquente, souvent sans rapport avec les activités de codage quotidiennes ou tout simplement sans intérêt pour les cœurs et les esprits des développeurs. Secure Code Warrior cherche à changer cela - apprendre le codage sécurisé peut être amusant, et avec le soutien de Bugcrowd, ce message peut être diffusé largement dans la communauté qui nous tient tant à cœur et que nous cherchons à encourager.

En fin de compte, nous devons parvenir à ce que la sécurité des logiciels soit synonyme de qualité des logiciels ; les enjeux sont tout simplement trop importants aujourd'hui pour qu'il en soit autrement. Et grâce à ce partenariat, je pense que nous pouvons faire en sorte que les développeurs soient réellement enthousiasmés par le développement sécurisé. Un environnement florissant de sensibilisation à la sécurité et une culture positive sont essentiels, et je ne peux pas imaginer une autre entreprise plus parfaite pour nous permettre d'y parvenir.

Soyez attentifs : le débat sur la sécurité est sur le point de basculer radicalement vers la gauche.

기기 암호화는 Android 기기의 모든 데이터를 암호화하는 프로세스입니다.Android 디바이스에서 이 기능을 활성화하면 사용자가 생성한 모든 데이터가 스토리지에 기록되기 전에 즉시 암호화됩니다.이렇게 하면 데이터가 보호되므로 권한이 없는 사람이 데이터에 액세스하려고 해도 데이터를 읽을 수 없게 됩니다.이는 스마트폰 장치에 특히 유용한 기능인데, 이는 사용자가 휴대하고 다니기 때문에 다른 컴퓨팅 장치보다 분실이나 도난이 발생하기 쉽기 때문입니다.호기심 많은 파인더나 도둑은 핸드폰을 잠금 해제하지 못하면 데이터에 접근할 수 없습니다.

안드로이드는 두 가지 유형 장치 암호화: 전체 디스크 암호화 및 파일 기반 암호화

전체 디스크 암호화

전체 디스크 암호화는 API 레벨 19 (Android 4.4 KitKat) 에서 도입되었지만 API 레벨 21 (안드로이드 5.0 롤리팝) 의 새로운 기능이 실제로 사용하기 시작했습니다.전체 디스크 암호화는 단일 키를 사용하여 전체 기기의 사용자 데이터 파티션을 보호합니다.키는 사용자 자격 증명으로 보호되며, 디스크의 어떤 부분에도 액세스할 수 있으려면 부팅 시 키를 입력해야 합니다.

이는 보안에도 좋지만 사용자가 자격 증명을 입력할 때까지 장치의 대부분의 기능을 사용할 수 없다는 의미이기도 합니다.즉, 기기를 재부팅한 후 잠금을 해제하지 않으면 알람과 같은 일부 기능이 작동하지 않고 서비스를 사용할 수 없으며 휴대폰이 전화를 받을 수 없습니다.이러한 이유로 두 번째 암호화 모드가 만들어졌습니다.

파일 기반 암호화

기기 암호화의 두 번째 모드인 파일 기반 암호화는 API 레벨 24 (Android 7.0 Nougat) 부터 사용할 수 있었습니다.이 모드에서는 각기 다른 파일을 각각 잠금 해제할 수 있는 서로 다른 키로 암호화합니다.이 암호화 모드에서는 다이렉트 부트 이 모드에서는 암호화된 장치를 잠금 화면으로 바로 부팅하여 장치 잠금을 해제하기 전에 이전에 누락된 기능을 활성화할 수 있습니다.

Direct Boot를 사용하면 기기가 잠금 해제되기 전에 제한된 컨텍스트 내에서 앱을 작동할 수 있습니다.이렇게 하면 사용자 정보를 손상시키지 않고도 앱이 예상대로 작동할 수 있습니다.이 기능을 제공하려면 Android 기기에 다음과 같은 두 개의 저장 위치가 필요합니다.

1. 자격 증명 암호화 스토리지.기본 저장 위치, 사용자가 기기를 잠금 해제한 후에만 사용할 수 있습니다.
2. 디바이스 암호화 스토리지.직접 부팅 모드에서 사용할 수 있으며 사용자가 장치를 잠금 해제한 후에 사용할 수 있습니다.

직접 부팅 모드에서 실행되는 동안 앱이 데이터에 액세스해야 하는 경우 기기 암호화 저장소를 사용해야 합니다.하지만 보안에 미치는 영향을 염두에 두세요!기기 암호화 스토리지는 민감한 데이터를 저장하는 데 사용해서는 안 됩니다!기기 암호화 저장소는 기기가 성공적으로 부팅되는 즉시 사용할 수 있는 키로 암호화됩니다.사용자만 액세스할 수 있는 모든 데이터는 기본 위치인 자격 증명 암호화 저장소에 저장해야 합니다.

암호화가 무엇인지, 왜 암호화가 중요한지 자세히 알아보려면 다음을 참조하세요. 더 비디오 시큐어 코드 워리어 포털에서또는 몇 가지 플레이를 통해 암호화에 대한 지식을 테스트해 볼 수도 있습니다. 도전.

디바이스에 대한 단계별 가이드가 필요하신가요?확인해 보세요 이 기사 픽셀 프라이버시의 빌 헤스가 작성했습니다.

새로운 것을 배웠기를 바랍니다.다음 주에 봐요!

자격 증명 암호화 저장소는 기본 저장소 위치이며 사용자가 장치를 잠금 해제한 후에만 사용할 수 있습니다.

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

새로운 연구에서는 양질의 보안 교육의 이점을 탐구합니다.

품질 보안 코드 교육이 조직에 미치는 잠재적 영향은 무엇이며 가치 있는 투자가 될 수 있을까요?이에 대한 답을 찾기 위해 Secure Code Warrior가 Evans Data Corp*와 함께 수행한 보안 코딩, 보안 코드 관행 및 보안 운영에 대한 개발자의 태도에 대한 최근 연구에서 얻은 몇 가지 인사이트를 살펴보겠습니다.
‍

개발자와 관리자에게 교육을 통해 코딩 방식이 어떻게 바뀌었는지 물었을 때 각 집단은 약간씩 다르게 반응했습니다.이러한 차이는 개발자가 작업에 접근하는 방식과 소프트웨어 개발 수명 주기 내에서의 역할과 일치했습니다.하지만 전반적으로 품질 보안 코드 교육의 영향이 압도적으로 긍정적이라는 것이 기본 주제입니다.

55% 의 개발자는 좋은 교육을 통해 코딩 기술에 대한 자신감이 높아졌다고 답했으며, 53% 는 좋은 교육을 통해 자신의 코드를 디버깅하고 테스트할 때 더 주의를 기울일 수 있다고 답했습니다.

가장 중요한 점은 53% 가 코드를 작성할 때 보안에 더욱 신경을 썼기 때문에 취약성과 재작업이 줄어들었다고 답했다는 것입니다.

소프트웨어 출시 시간을 단축하는 관리자

관리자의 43% 가 보안 코드 교육을 통해 조직이 코드를 디버깅하고 테스트할 때 더욱 주의를 기울일 수 있다는 데 동의하지만, 상위 두 가지 변경 사항은 관리자의 책임을 반영합니다. 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

27 janvier 2018. Secure Code Warrior L'anniversaire d'A. K. tombe un jour après le jour de l'Australie (Australia Day). J'ai réalisé, en contemplant une autre année fantastique, que j'ai en fait deux enfants de trois ans dans ma vie, un professionnel et un humain... avec des similitudes remarquables :

• Il est difficile de les mettre au lit le soir sans une routine adéquate.

"Je lis le dernier courriel qui vient d'arriver... ou attendez, je dois rapidement me synchroniser au téléphone avec notre équipe aux États-Unis... ou cette proposition doit vraiment être envoyée avant ce soir. Et zut. Il est encore minuit passé."

• Ils vous rendent si fiers lorsqu'ils réussissent quelque chose

Même si vous n'avez pas dormi correctement pendant trois semaines, que vous n'avez pas eu le temps de faire de l'exercice ou que vous avez simplement dû nettoyer un gâchis... votre projet pilote a démontré l'impact sur les compétences des développeurs en matière de sécurité et le client est heureux de s'engager à travailler avec nous pour trois années supplémentaires ! BOOM ! Des pics d'énergie. Et des gâteaux partout. Soudain, le manque de sommeil n'a plus autant d'importance.

• Ils grandissent si vite

L'époque où vous pouviez vous éclipser avec l'équipe à Bali et travailler depuis la maison de la plage sur les prochaines fonctionnalités de la plateforme est révolue. Notre start-up a connu une croissance de 4 à 6 fois au cours de l'année écoulée (selon que vous mesurez le personnel, les clients ou le chiffre d'affaires), avec une ingénierie à Sydney (AU) et à Bruges (BE) et des ventes et du marketing aux États-Unis, en Europe et en Australie. Je me souviens qu'il y a un an, j'étais très enthousiaste à l'idée d'avoir l'une des grandes banques australiennes comme client. Aujourd'hui, nous travaillons avec 10 des 100 premières institutions financières mondiales ainsi qu'avec certaines des principales entreprises de télécommunications et de technologie qui construisent la prochaine génération de services en ligne (remarque : je suis toujours très fier des banques australiennes, qui ont été nos premiers clients !)

Nous avons grandi très vite sur de nombreux fronts, mais l'une des étapes clés de l'année dernière a été la définition d'une vision pour notre entreprise. Au cours des premières années, nous étions tellement concentrés sur la construction, l'exécution et la trésorerie que nous avons souvent oublié de nous arrêter et de réfléchir à ce que nous voulions exactement réaliser. Plus les gens rejoignent Secure Code Warrior et plus nous amenons de clients à bord, plus il était important d'avoir une vision cohérente et de comprendre où nous allons. C'est ce que nous avons fait en 2017.

Une autre étape clé a été franchie dans le domaine de la technologie. Nous avons réalisé très tôt que le développement des compétences d'un développeur n'est que le début du parcours de codage sécurisé. Ils ont besoin d'outils autour d'eux pour que la sécurité soit intégrée et facile à mettre en œuvre, plutôt qu'une réflexion après coup ou une chose à laquelle on pense quand on a fini d'écrire le code. Non, la sécurité doit être mise en place dès le départ, lors de l'écriture du code.

Notre équipe a travaillé très dur pour écrire des plugins de coaching en sécurité pour les IDE les plus courants (IntelliJ, Visual Studio, Android Studio pour n'en citer que quelques-uns) qui aideront réellement le développeur à écrire un code plus sûr. Il ne s'agit pas seulement de signaler les faiblesses potentielles en matière de sécurité, mais d'être un véritable coach et d'intervenir lorsque les développeurs écrivent un code qui n'est pas conforme aux pratiques de pointe en matière de sécurité. Le plug-in de coaching en sécurité s'appelle Sensei et il permet vraiment à un développeur d'être formé sur place (micro-apprentissage) et, dans certains cas, il offre une option d'autocorrection pour corriger le code instantanément.

Je suis très enthousiaste à l'idée de ce que les 12 prochains mois nous réservent. Nous constatons déjà que la sécurité des logiciels n'est plus seulement l'affaire des grandes entreprises de développement comme les banques, les sociétés de télécommunications ou les entreprises technologiques. Des organisations de tous types continuent d'être compromises par des faiblesses logicielles et bien que l'injection SQL puisse enfin disparaître, il y en a toute une série d'autres qui attendent de prendre sa place.

Les clients, les marchés et les conseils d'administration de tous les secteurs attendent désormais des entreprises qu'elles protègent la sécurité de leur code. La conformité continuera à pousser les organisations dans cette direction (par exemple, le GDPR pour tous ceux qui font des affaires en Europe, les lois sur les violations de données qui arrivent en Australie, etc.)

Cela signifie que je suis convaincu que notre plateforme SCW va poursuivre sa croissance rapide dans le monde entier et dans de nouvelles industries. C'est une bonne nouvelle pour notre entreprise, bien sûr, mais cela aide aussi mon équipe à concrétiser notre vision, qui, je crois, est très intéressante pour l'ère du logiciel dans laquelle nous vivons.

Les développeurs qui utilisent nos outils peuvent réellement jouer un rôle plus proactif dans la sécurité de leur entreprise, et c'est ce qu'ils font. Ils disposent des compétences et des outils nécessaires pour écrire un code sécurisé et constituer la première ligne de défense de leur entreprise.

Je ressens la même chose en tant que parent d'un enfant de trois ans et PDG de Secure Code Warrior: chaque année est meilleure que la précédente. J'ai hâte de voir comment l'enfant de quatre ans va évoluer !

Notre vision est de permettre aux développeurs d'être la première ligne de défense de leur organisation en rendant la sécurité très visible et en leur fournissant les compétences et les outils nécessaires pour écrire un code sécurisé dès le début.

어디서든 개발자를 만나세요

더 빠르고 안전한 릴리스를 위해 DevSecOps를 찾고 있는 조직은 통합 기술 스택으로 개발자 생산성을 최적화하는 것이 중요하다는 것을 알고 있습니다.Secure Code Warrior의 소프트웨어 통합은 개발자가 GitHub, Jira 등과 같이 매일 사용하는 도구에 통합된 안전한 개발 리소스를 제공합니다.

Secure Code Warrior를 사용하면 보안 코드 프로그램을 선호하는 제품 및 개발자의 워크플로우에 직접 구축하여 적시 수정은 물론 더 까다로운 학습 결과를 얻을 수 있습니다.

더 빠른 치료로 취약성 감소

취약점을 찾아 해결하는 것은 일부 조각과 유용한 표지 그림 없이 큰 퍼즐을 푸는 것과 같을 수 있습니다. 강력한 솔루션으로 완료하는 데 며칠, 몇 주, 심지어 몇 달이 걸릴 수도 있습니다.이는 개발자가 문제를 해결하는 방법을 모르는 경우 특히 어려울 수 있습니다. 이전에 문제를 경험한 적이 없거나 테스트되지 않았거나 검증되지 않은 솔루션을 배포하는 것을 주저하기 때문입니다.

EdgeScan 2022 취약성 통계 보고서에 따르면 전체 스택에서 발견된 취약점에 대한 평균 치료 시간 (MTTR) 은 다음과 같습니다. 57.5일 (엣지스캔 2022 취약성 통계 보고서).

이는 중요한 데이터가 손상되고 신뢰가 손실되며 귀중한 개발자 생산성이 낭비될 수 있는 중요한 시기입니다. 배포된 솔루션에 대한 지식이나 신뢰가 부족하기 때문에 코드 릴리스 속도가 느려지고 빠른 수정이나 엉성한 패치 워크로 결국 더 많은 기술 부채가 누적될 수 있습니다.

Secure Code Warrior의 통합은 신뢰할 수 있는 수정 조언을 제공하므로 개발자는 흐름을 유지하면서 자신 있게 보안 버그를 해결할 수 있습니다.AppSec은 개발자가 소스에서 직접 수정 조치를 취할 수 있도록 함으로써 위험 모니터링과 조직의 보안 태세 강화에 집중할 수 있습니다.

작업 항목에 포함된 상황별 보안 코딩 지침을 통해 개발자는 탐지된 취약성과 해결 방법에 대해 자세히 알아보는 데 즉각적인 도움을 받을 수 있습니다. 따라서 MTTR을 줄일 수 있을 뿐만 아니라 소스 코드에서 취약성을 사전에 줄이는 가치 있고 끈끈한 학습 결과를 얻을 수 있습니다.

팀 전반에서 학습을 확장하세요

SCORM LMS 통합

SCORM은 공유 가능한 콘텐츠 객체 참조 모델을 의미하며 e-코스의 국제 표준입니다.강좌가 SCORM 형식으로 게시된 경우 거의 모든 LMS (학습 관리 시스템) 에서 이를 인식할 수 있습니다.SCORM을 사용하면 쉽게 관리할 수 있습니다. 보안 코드 교육 다른 교육 플랫폼과 함께 프로그램을 한 곳에서 이용할 수 있습니다.

코드를 발송하기 전에 숙련도 확인

Okta 워크플로를 위한 보안 코드 워리어 커넥터 플로우에 내장할 수 있는 보안 숙련도 검사를 통해 안전하지 않은 코드가 코드베이스에 유입되는 것을 방지하는 데 도움이 됩니다.GitHub 리포지토리와 같은 코드베이스에서 작업할 때 필수 강의 및 평가를 기본 코딩의 자격 요건으로 설정할 수 있습니다.이를 통해 리더는 각 개발자가 관련 코드베이스에서 작업할 준비가 되었는지 확인할 수 있어 조직 전체의 보안 태세를 강화할 수 있습니다.

각 개별 개발자가 코드 커밋에 대한 리포지토리 액세스 권한을 부여하는 데 필요한 보안 코딩 기술을 습득하도록 하여 전체 소프트웨어 개발 수명 주기에 보안을 도입합니다.이러한 통합을 통해 개발자는 SCW의 매우 흥미로운 플랫폼을 통해 최신 보안 사례를 학습하고 수동 코드 검토로 인한 부담을 일부 줄여 엔지니어링 시간을 절약하여 품질 저하 없이 더 많은 기능을 출시할 수 있습니다.

Okta+SCW에 대해 자세히 알아보기또는 참조 데모 여기.

코드 커밋 시 저스트 인 타임 지원

GitHub용 SCW를 사용하면 GitHub 워크플로우 내에서 상황에 맞는 교육을 받을 수 있습니다. SARIF 파일에 있거나 작업 중인 이슈 및 풀 리퀘스트 내에서 직접 확인할 수 있습니다.이를 통해 개발자는 가장 필요할 때 지식을 얻을 수 있어 품질 코드를 더 빠르게 출시할 수 있습니다.이러한 통합은 이해 없이 자주 적용되는 패치만 가능하게 하는 것이 아닙니다.취약한 코드를 빠르게 인식할 수 있도록 우수하고 안전한 코딩 패턴을 지속적으로 강화합니다.

SCW+깃허브에 대해 더 알아보기또는 참조 데모

GitLab에 통합된 실행 가능한 보안 코딩 지침 취약성 보고서의 취약성 세부 정보 섹션에 관련성이 높은 Secure Code Warrior 교육 링크를 포함합니다.이는 궁극적으로 이러한 통합을 통해 학습과 지식 적용 간의 시간 격차를 줄여 향후 사용을 보장하는 데 도움이 됩니다.예를 들어 취약성 스캐너가 애플리케이션 코드에서 CSRF (Cross-Site Request Forgery) 를 탐지한 경우 관련 교육 링크를 통해 취약성 세부 정보가 업데이트됩니다.

“우리 플랫폼의 보안 코딩 전반에 걸쳐 Secure Code Warrior의 광범위한 컨텍스트 학습을 제공함으로써 개발자들이 처음부터 보안을 최우선으로 받아들이고 시간을 절약할 수 있을 뿐만 아니라 새로운 기술을 개발하는 데도 도움이 될 것입니다.” - Nima Badiey, GitLab VP

자세히 알아보기 SCW+ 깃랩에 대해

시놉시스 시커 통합 보안 코드 워리어 리소스, 비디오 및 취약점 발견에 대한 교육 링크를 Seeker 내에 포함합니다.이를 통해 Seeker 내에서 쉽게 액세스할 수 있는 교육 지침을 통해 취약점을 식별하고 해결하는 마이크로 러닝을 통해 업계 표준 및 규정을 준수할 수 있습니다.

시놉시스+SCW에 대해 자세히 알아보기

지금 필요할 때 티켓 내부의 도움을 받으세요

보안 결함을 찾는 데 그치지 말고 다음을 통해 문제를 해결하는 데 도움을 받으십시오. Jira용 보안 코드 워리어. 개발자는 Jira Issue Tracker에서 바로 상황에 맞는 교육을 받을 수 있어 개발자가 가장 필요할 때 지식에 액세스하여 고품질 코드를 더 빠르게 출시할 수 있습니다.Secure Code Warrior for Jira는 이러한 문제 세부 정보를 감지하고 개발자에게 익숙한 환경 내의 특정 교육 비디오에 액세스하여 이러한 문제를 해결하는 방법을 배울 수 있는 기회를 제공합니다.개발팀은 상황에 맞는 마이크로 러닝을 통해 전체 코드베이스의 취약점을 줄이고 Jira를 통한 추적 및 보고를 통해 이를 완벽하게 파악할 수 있습니다.

자세히 알아보기 SCW + 지라에 대해

빠른 속도로 보안 코드 작성

Secure Code Warrior의 기술 스택 통합을 통해 일반적인 취약점에 대한 업계에서 신뢰할 수 있는 지침과 솔루션을 통해 마이크로 러닝과 빠른 교정이 가능합니다.

• 교육 링크는 이슈 및 풀 리퀘스트에 댓글로 첨부되어 있어 필요할 때 지침을 쉽게 이용할 수 있습니다.

• 콘텐츠는 관련성이 높고 CWE (공통 취약점 열거) 또는 OWASP (오픈 웹 애플리케이션 보안 프로젝트) 참조를 기반으로 가져옵니다.

• 광범위한 지원 범위가 제공된다는 것은 학습 리소스가 세계 최고의 보안 코딩 교육 컬렉션에서 제공된다는 것을 의미합니다.

수십 년 동안 알려진 일반적인 취약점은 대응 조치로 인해 SDLC 내에서 계속 존재합니다.스캐닝 툴과 침투 테스팅은 대개 애플리케이션이 이미 프로덕션 단계에 들어간 이후에만 문제를 찾아냅니다.오탐과 네거티브 요소를 여럿 찾아내느라 수작업으로 검토해야 하는 등 속도가 매우 느리기로 악명이 높으며 문제의 원인이나 원인을 거의 다루지 않습니다.

개발자의 워크플로우 내에서 마이크로 러닝 및 개선 조언을 제공하고 역량을 강화하면 개발 프로세스 초기에 보안 약점을 발견하여 비용이 많이 들거나 나중에 악용될 수 있는 취약점을 남기기 전에 파악할 수 있습니다.Secure Code Warrior 통합은 개발자가 근무하는 곳에서 유용하며, 개발자가 취약점을 더 빨리 찾아 수정하도록 도울 뿐만 아니라 신뢰할 수 있는 리소스와 간단한 지침을 통해 학습하여 기술을 향상시키고 보안을 소프트웨어 개발 수명 주기의 중요한 구성 요소로서 강화합니다.

자세히 알아보고 싶으신가요?

• Product Talk 웨비나를 시청하여 SCW의 모든 흥미로운 통합에 대해 알아보십시오.
• Okta용 데모를 확인해 보세요
• GitHub용 데모 보기
• 시큐어 코드 워리어를 무료로 사용해 보세요

이 기사의 한 버전이 에 게재되었습니다. 사이버 보안 내부자. 여기에서 업데이트 및 신디케이트되었습니다.

‍

대규모 언어 모델 (LLM) 코드 작성자부터 정교한 에이전트 AI 에이전트에 이르기까지 다양한 인공 지능 어시스턴트의 채택은 소프트웨어 개발자에게 풍부한 이점을 제공합니다.그러나 MIT의 새로운 연구 결과에 따르면 AI에 대한 의존도가 높으면 사용자가 비판적 사고 능력을 잃을 수 있다는 경고가 하나 있습니다.

AI 채택과 함께 AI 관련 보안 위험이 커진 소프트웨어 환경을 고려할 때 이러한 인지 적합성 상실은 실제로 치명적인 결과로 이어질 수 있습니다.개발자와 조직은 소프트웨어 개발 라이프사이클 (SDLC) 초기에 보안 취약성을 사전에 식별, 이해 및 완화하는 것이 윤리적으로 필수적입니다.놀랍게도 오늘날 많은 조직을 설명하듯이 이러한 의무를 소홀히 하는 사람들은 잠재적 보안 위협의 급격한 증가에 직면하게 되며, 그 중 일부는 AI에 직접 기인합니다.

논쟁은 AI를 사용할지 여부가 아닙니다. 생산성과 효율성의 이점은 무시하기에는 너무 크기 때문입니다.하지만 진짜 문제는 어떻게 하면 가장 효과적으로 적용할 수 있느냐는 것입니다. 즉, 생산량 증대를 극대화하는 동시에 보안을 보호하는 것입니다.그리고 코드의 출처를 불문하고 코드를 깊이 이해하고 있는 보안에 능숙한 개발자가 이 작업을 가장 잘 수행할 수 있습니다.

AI에 대한 과도한 의존은 인지 기능 저하를 초래합니다

더 MIT 미디어 랩의 연구6월 초에 발표된 이 보고서는 보스턴 지역 5개 대학의 54명의 학생들이 에세이를 작성하면서 인지 기능을 테스트했습니다.학생들은 세 그룹으로 나뉘었습니다. LLM (Large Language Model) 을 사용하는 그룹, 검색 엔진을 사용하는 그룹, 외부 도움 없이 올드 스쿨에 진학한 학생들이었습니다.연구팀은 뇌파검사 (EEG) 를 사용하여 참가자의 뇌 활동을 기록하고 인지 참여도와 인지 부하를 평가했습니다.연구팀은 구식 “뇌 전용” 그룹이 가장 강력하고 가장 광범위한 신경 활동을 보인 반면, 검색 엔진을 사용하는 그룹은 중간 정도의 활동을 보였고 LLM (이 경우 OpenAI의 ChatGPT-4) 을 사용하는 그룹은 가장 적은 양의 뇌 활동을 보였다는 것을 발견했습니다.

이것은 그리 놀라운 일이 아닐 수도 있습니다. 결국 자신을 대신해 사고할 수 있는 도구를 사용하면 생각을 덜 하게 될 것입니다.하지만 이 연구에 따르면 LLM 사용자는 논문과의 연관성이 약한 것으로 나타났습니다. 83% 의 학생들이 수필 완료 후 단 몇 분만에 에세이의 내용을 기억하는 데 어려움을 겪었고 참가자 중 누구도 정확한 인용문을 제시하지 못했습니다.다른 그룹에 비해 저자에 대한 주인의식이 결여된 상태였습니다.두뇌 전용 참가자는 주인의식이 가장 높고 뇌 활동 범위가 가장 넓었을 뿐만 아니라 가장 독창적인 논문을 작성했습니다.LLM 그룹의 연구 결과는 좀 더 동질적이었으며, 실제로 심사위원들은 이를 AI의 연구물로 쉽게 식별할 수 있었습니다.

개발자의 관점에서 볼 때 주요 결과는 AI 사용으로 인한 비판적 사고의 감소입니다.물론 AI에 한 번 의존한다고 해서 필수적인 사고 능력이 손실되지는 않을 수 있지만, 시간이 지나도 계속 사용하면 이러한 기술이 위축될 수 있습니다.이 연구는 사용자가 AI를 돕는 대신 AI가 사용자를 돕도록 함으로써 AI를 사용하는 동안 비판적 사고를 유지할 수 있는 방법을 제안합니다. 하지만 진정한 강조점은 개발자가 안전한 소프트웨어를 구축하는 데 필요한 보안 기술을 갖추고 이러한 기술을 업무의 일상적이고 필수적인 부분으로 사용하도록 하는 것입니다.

개발자 교육: AI 기반 에코시스템에 필수

MIT와 같은 연구가 모든 분야에서 발전하고 있는 AI 채택을 막지는 못할 것입니다.스탠포드 대학교의 2025 AI 인덱스 리포트 2023년에는 55% 에 비해 2024년에는 78% 의 조직이 AI를 사용했다고 보고한 것으로 나타났습니다.이러한 성장은 계속될 것으로 예상됩니다.하지만 사용 증가는 위험 증가로 이어집니다. 보고서에 따르면 AI 관련 사이버 보안 사고는 같은 기간 동안 56% 증가했습니다.

스탠포드의 보고서는 다음과 같은 중요한 필요성을 강조합니다. 개선된 AI 거버넌스또한 조직은 보안 보호 장치를 구현하는 데 어려움을 겪고 있는 것으로 나타났습니다.거의 모든 조직이 AI의 위험을 인식하고 있지만 AI에 대해 조치를 취하고 있는 조직은 2/3도 되지 않아 수많은 사이버 보안 위협에 취약해지고 점점 더 엄격해지는 규정 준수 요구 사항을 위반할 수 있습니다.

해답이 AI 사용을 중단하는 것이 아니라면 (아무도 하지 않을 것입니다), AI를 더 안전하고 안전하게 사용하는 것이어야 합니다.MIT 연구는 이 문제를 해결하는 방법에 대한 유용한 단서를 제공합니다.연구의 네 번째 세션에서 연구자들은 LLM 사용자를 두 그룹으로 나누었습니다. 하나는 ChatGPT에 도움을 청하기 전에 혼자서 에세이를 시작한 사람들 (이 연구에서는 Brain-to-LLM 그룹이라고 함) 이고, 다른 하나는 ChatGPT가 개인적인 관심을 기울이기 전에 첫 번째 초안을 작성한 사람들 (LLM-to-Brain 그룹) 이었습니다.AI 도구를 사용하여 이미 초안을 작성한 에세이를 다시 작성한 Brain-to-LLM 그룹은 기억력과 두뇌 활동이 더 높았으며, 일부 영역은 검색 엔진 사용자와 비슷했습니다.AI가 에세이를 시작하도록 허용한 LLM-To-Brain 그룹은 신경 활동이 덜 조율되고 LLM 어휘 사용에 편향된 태도를 보였습니다.

Brain-to-LLM 접근 방식은 사용자의 두뇌를 좀 더 예리하게 만드는 데 도움이 될 수 있지만 개발자가 소프트웨어를 안전하게 작성하고 AI 생성 코드의 오류 및 보안 위험을 비판적으로 평가하기 위한 특정 지식도 필요합니다.개발자들은 취약점과 같은 보안 결함을 유발하는 경향을 포함하여 AI의 한계를 이해해야 합니다. 신속한 주사 공격.

이를 위해서는 개발자들이 전사적 보안 우선 문화의 일환으로 효과적이고 유연하며 실습적이고 지속적인 기술 향상을 받을 수 있는 인간 중심의 SDLC를 보장하기 위해 엔터프라이즈 보안 프로그램을 정비해야 합니다.개발자는 빠르게 진화하는 정교한 위협, 특히 소프트웨어 개발에서 AI의 중요한 역할로 인해 발생하는 위협에 대응하기 위해 지속적으로 기술을 연마해야 합니다.이를 통해 예를 들어 점점 더 흔해지는 프롬프트 인젝션 공격으로부터 보호할 수 있습니다.하지만 이러한 보호가 제대로 작동하려면 조직에 보안 설계 패턴과 위협 모델링에 초점을 맞출 수 있는 개발자 중심의 이니셔티브가 필요합니다.

Conclusion

LLM 또는 에이전트 에이전트가 어려운 작업을 수행할 때 사용자는 수동적인 구경꾼이 됩니다.이 연구의 저자들은 이로 인해 “비판적 사고력이 약해지고, 자료에 대한 깊은 이해가 떨어지며, 장기 기억력 형성이 저하”될 수 있다고 말했습니다.인지적 참여 수준이 낮으면 의사 결정 능력도 저하될 수 있습니다.

조직은 사이버 보안과 관련하여 비판적 사고의 부재를 감당할 수 없습니다.고도로 분산된 클라우드 기반 환경의 소프트웨어 결함이 사이버 공격자의 최대 표적이 되고 있기 때문에 사이버 보안은 개발자, AI 어시스턴트 또는 에이전트 에이전트가 생성한 코드의 보안을 보장하는 것에서 시작됩니다.AI의 모든 기능 중에서도 조직은 그 어느 때보다 고도로 연마된 문제 해결 능력과 비판적 사고 능력을 필요로 합니다.그리고 이는 AI에 아웃소싱할 수 없습니다.

SCW Trust Agent의 새로운 AI 기능은 보안을 희생하지 않고도 SDLC에서 AI 채택을 자신 있게 관리하는 데 필요한 심층적인 관찰 및 제어 기능을 제공합니다. 자세히 알아보기.

기업이 규정 준수를 위해서뿐만 아니라 중요한 비즈니스 요구 사항으로 Secure by Design 원칙을 제품 개발 프로세스에 포함시켜야 한다는 사실이 점점 더 분명해지고 있습니다.이 지침은 기업이 제품을 시장에 출시하기 전에 제품의 악용 가능한 결함을 식별하여 완화할 수 있도록 하기 위한 것입니다.이러한 지침을 단순한 애드온이 아닌 기본 기둥으로 취급하는 조직에서 이러한 원칙에 따라 구축한 제품은 경쟁이 심화되는 이 시장에서 앞서 나가는 경향이 있습니다.

하지만 미국 정부의 사이버 보안 및 인프라 보안국 (CISA) 이 발표한 지 2년이 지난 지금 보안을 고려한 설계 가이드라인, 실제 구현은 여전히 업계 전반에서 풀기 어려운 수수께끼입니다.이러한 원칙이 중요하다는 것은 누구나 알고 있지만, 어떻게 하면 대규모로 효과적으로 구현할 수 있을까요?

최신 백서에서, 공동 창립자인 Pieter Danhieux 박사와 Matias Madou 박사 (Dr. Matias Madou) 는 CISO, AppSec 리더 및 보안 전문가를 포함한 20명 이상의 엔터프라이즈 보안 리더와 함께 이 퍼즐의 핵심 요소를 파악하고 Secure by Design 운동의 이면에 있는 현실을 알아냈습니다.보안 팀 전체가 같은 포부를 갖고 있지만, 플레이북을 공유하지는 않았습니다.

몇 가지 주요 결과를 확인해 보십시오.

• 대부분의 보안 실무자와 비즈니스 리더는 Secure by Design 이니셔티브의 아이디어와 가치에 동의하고 있지만, 여전히 해석의 여지가 있으며 이를 구현하기 위한 업계 전반의 표준 접근 방식은 없습니다.

• 위협 모델링은 단순히 규정 준수 체크리스트에서 빠질 수 있는 것이 아닙니다. 이는 보안에 정통한 개발자와 AppSec 대응자가 위험을 악용하기 전에 미리 대비할 수 있도록 지원하는 중요하고 일관된 방법입니다.

• 양날의 검인 AI - AI는 혁신적이면서도 공격 범위를 크게 확장하는 강력한 보안 위험입니다.폭발적인 성장으로 인해 위험이 빠르게 진화하고 있습니다. 숙련되지 않은 개발자와 리소스가 부족한 AppSec 팀은 이러한 위험을 완화하는 데 어려움을 겪는 경우가 많습니다.

문제는 Secure by Design (Secure by Design) 원칙을 적용하는 것의 중요성에 대한 이해 부족이 아닙니다. 보안 소프트웨어의 필요성은 기본적인 요구 사항이자 기본 기대치가 되었습니다.부족한 것은 이러한 원칙을 소프트웨어 개발 라이프사이클 전반에 포함하기 위한 조정되고 확장 가능한 전략입니다.

또한 성공적인 출시를 결정하기 위한 명확한 벤치마크나 측정 가능한 결과가 부족한 것 같습니다.이러한 지표가 없다면 팀은 자신의 노력이 진정으로 영향을 미치고 있는지 짐작할 수밖에 없습니다.현재로선 전선이 단합된 것 같지만 전략을 공유하지는 않습니다.

보안 설계는 필수적이고 불가피하며 규정 준수가 높은 부문에만 국한되지 않습니다.개발자에게도 부담을 주지 말고 권한을 부여해야 합니다.적절한 기술, 도구 및 지원을 갖추면 이들은 본질적으로 단순한 빌더가 아니라 방어자가 되어 가장 중요한 부분, 즉 원천에서 보안을 구현합니다.

지금 다운로드 팀이 강력한 개발자 위험 관리 전략과 정밀 측정을 활용하여 기업 내에서 성공적이고 통합된 Secure by Design 이니셔티브를 추진할 수 있는 방법을 알아보십시오.

Les développeurs de logiciels ont montré qu'ils étaient prêts et désireux d'utiliser l'intelligence artificielle générative (IA) pour écrire du code, et ils ont généralement obtenu des résultats favorables. Mais de nombreux signes indiquent également qu'ils pourraient jouer un jeu dangereux.

Selon une enquête récente de GitHub, plus de 90 % des développeurs américains utilisent des outils de codage de l'IA, citant des avantages tels que des délais d'exécution plus courts, une résolution rapide des incidents et un environnement plus collaboratif, ce qu'ils considèrent comme important. L'utilisation d'outils d'IA permet aux développeurs de se décharger des tâches routinières, ce qui leur permet de se consacrer à des travaux plus créatifs qui profitent à leur entreprise et, non sans raison, réduisent les risques d'épuisement professionnel.

Toutefois, des études ont également montré que les outils d'IA ont tendance à introduire des failles lors de l'écriture du code. Une enquête menée par Snyk a révélé que, bien que 75,8 % des personnes interrogées affirment que le code de l'IA est plus sûr que le code humain, 56,4 % admettent que l'IA introduit parfois des problèmes de codage. Fait alarmant, 80 % des personnes interrogées ont déclaré qu'elles contournaient les politiques de sécurité du code de l'IA au cours du développement.

Depuis le lancement du ChatGPT d'OpenAI en novembre 2022, l'utilisation de modèles d'IA générative s'est répandue à la vitesse de l'éclair dans le processus de développement du code dans les services financiers, comme dans de nombreux autres domaines. L'émergence rapide d'autres modèles, tels que GitHub Copilot, OpenAI Codex et une liste croissante d 'autres modèles, suggère que nous n'avons fait qu'effleurer la surface de ce que l'IA générative peut faire et de l'impact qu'elle peut avoir. Mais pour que cet impact soit positif, nous devons nous assurer que le code qu'elle génère est sécurisé.

Les bogues de codage peuvent se propager rapidement

Qu'il soit créé par des développeurs humains ou des modèles d'IA, le code contiendra toujours des erreurs. L'IA contribuant à accélérer le développement du code pour répondre aux demandes sans cesse croissantes dans les environnements informatiques hautement distribués et basés sur le cloud, les risques de propagation à grande échelle d'un mauvais code avant qu'il ne soit détecté pourraient augmenter. 

Les modèles d'IA formés à l'écriture de code ingèrent des milliers d'exemples de code qui exécutent diverses tâches, puis ils peuvent s'inspirer de ces exemples pour créer leur propre code. Mais si les échantillons à partir desquels il travaille contiennent des failles ou des vulnérabilités - qu'ils aient été créés à l'origine par un humain ou une autre IA - le modèle pourrait transférer ces failles dans un nouvel environnement. 

La recherche ayant montré que les modèles d'IA ne sont pas capables de reconnaître de manière fiable les failles dans le code qu'ils utilisent, il n'y a guère de défense intégrée contre la propagation des failles et des vulnérabilités. Non seulement l'IA commettra des erreurs de codage, mais elle répétera ses propres erreurs et celles d'autres sources jusqu'à ce que la vulnérabilité soit identifiée quelque part, peut-être sous la forme d'une violation réussie d'une entreprise utilisant le logiciel qu'elle a créé.

La véritable défense contre la prolifération des failles de codage réside dans la collaboration entre les humains et les modèles d'IA. Les développeurs humains devraient superviser la rédaction du code de l'IA et servir de garde-fou contre les pratiques de codage non sécurisées et le code vulnérable. Mais pour cela, les développeurs doivent être parfaitement formés aux meilleures pratiques de rédaction de code sécurisé afin de pouvoir identifier les erreurs de codage qu'une IA pourrait commettre et les corriger rapidement.

Les défis de la création de code d'IA et de la remédiation

L'explosion soudaine des grands modèles de langage (LLM) tels que ChatGPT a été une sorte d'épée à double tranchant. D'un côté, les entreprises et les utilisateurs quotidiens ont constaté des gains de productivité considérables grâce à l'utilisation de l'IA pour effectuer des tâches fastidieuses, onéreuses ou difficiles. D'un autre côté, de nombreux exemples montrent ce qui peut se passer lorsqu'on fait aveuglément confiance à l'IA pour effectuer le travail.

Les modèles d'IA ont commis des erreurs flagrantes, fait preuve de partialité et produit de véritables hallucinations. Dans de nombreux cas, les données d'entraînement inadéquates ou irresponsables étaient à l'origine du problème. La qualité d'un modèle d'IA dépend des données sur lesquelles il est entraîné. Il est donc essentiel que les données d'entraînement soient complètes et soigneusement vérifiées. Il est donc essentiel que les données d'entraînement soient complètes et soigneusement vérifiées. Mais même dans ce cas, certaines erreurs seront commises.

L'utilisation de l'IA pour le codage se heurte à de nombreux obstacles similaires. Il a été démontré que le code généré par l'IA contient une série de failles, telles que des vulnérabilités au cross-site scripting et à l'injection de code, ainsi que des attaques spécifiques à l'IA et à l'apprentissage machine (ML), telles que l'injection d'invite. Les modèles d'IA fonctionnent également comme une boîte noire car leurs processus ne sont pas transparents, ce qui empêche une équipe de sécurité ou de développement de voir comment l'IA parvient à ses conclusions. Par conséquent, le modèle peut répéter les mêmes erreurs à l'infini. Les mêmes lacunes qui peuvent affecter l'écriture du code s'appliquent également à l'utilisation de l'IA pour la remédiation du code et le respect des exigences de conformité. 

Le risque que des failles soient créées ou répétées par des modèles d'IA s'est accru au point que les LLM ont désormais leur propre liste des dix principales vulnérabilités de l'Open Web Application Security Project (OWASP).

Les développeurs et l'IA peuvent travailler ensemble pour créer du code sécurisé

Les inquiétudes concernant les failles potentielles du code généré par l'IA peuvent faire réfléchir certaines organisations, ne serait-ce que brièvement, avant d'aller de l'avant avec cette technologie. Mais les avantages potentiels sont trop importants pour être ignorés, d'autant plus que les développeurs d'IA continuent d'innover et d'améliorer leurs modèles. Il est peu probable que le secteur des services financiers, par exemple, remette le génie dans la bouteille. Les banques et les sociétés de services financiers sont déjà axées sur la technologie, et elles opèrent dans un domaine où elles sont toujours à la recherche d'un avantage concurrentiel. 

L'essentiel est de mettre en œuvre les modèles d'IA de manière à minimiser les risques. Cela signifie que les développeurs doivent être sensibilisés à la sécurité et formés de manière approfondie aux meilleures pratiques de codage sécurisé, afin qu'ils puissent écrire eux-mêmes du code sécurisé et surveiller de près le code produit par les modèles d'IA. En faisant travailler les moteurs d'IA et les développeurs humains dans un partenariat étroit, les développeurs ayant le dernier mot, les entreprises peuvent récolter les fruits d'une productivité et d'une efficacité accrues tout en améliorant la sécurité, en limitant les risques et en garantissant la conformité. 

Pour un aperçu complet de la manière dont le codage sécurisé peut contribuer à garantir le succès, la sécurité et les profits des entreprises de services financiers, vous pouvez lire le guide Secure Code Warrior qui vient de paraître : Le guide ultime des tendances en matière de sécurité dans les services financiers.

‍

‍

Consultez les pages du Secure Code Warrior pour en savoir plus sur la cybersécurité, sur les menaces de plus en plus dangereuses et sur la manière dont vous pouvez utiliser des technologies et des formations innovantes pour mieux protéger votre organisation et vos clients.

‍