Informations sur le code sécurisé

Like many people in the security industry, I and several colleagues made the journey in March to the RSA Conference in San Francisco. Although an extremely busy time of year, it is truly one of my favorite events. One part I particularly look forward to is Bugcrowd's Mayhem at the Mint, which is a chance to relax and have a great time with peers and friends after long conference days.

This year was a little different, though. We had a lot to personally celebrate. As sponsors of the event, we had our own cocktail on the night (Secure Code Sangria, of course), but the thing that really made me want to party was our new partnership with Bugcrowd. It's official: we are joining forces in the fight to educate, empower and enlighten developers on secure coding.

I enjoyed and appreciated the enthusiasm expressed from the wider industry regarding this announcement, particularly the article and podcast episode from ITSPmagazine. In speaking to Bugcrowd's Casey Ellis and Jason Haddix, editor Sean Martin truly captured the essence of why we do what we do: it's because meaningful change takes a crowd. Bugcrowd has long recognized this, and working together to turn software engineers all over the world into security superheroes is a dream come true.

After more than twenty years of breaking stuff, finding and fixing vulnerabilities that have wreaked havoc on the world, it has become more apparent than ever that the conversation around security must change. "Hackers'aren't always the bad guys; their inherent skills are invaluable in the software fortification process, and we need to make a concerted effort to start left. It shouldn't be a novel concept to try out someday, it should be core to the software development lifecycle. To do this, we and Bugcrowd are committed to changing the perception many developers have of security: that it is an inconvenient blocker to building functionality and features.

Security training to date has been inadequate. Far too infrequent, often irrelevant to day-to-day coding activities or simply not engaging the hearts and minds of developers. Secure Code Warrior seeks to change that - learning about secure coding can be fun, and with Bugcrowd's support, this message can be spread far and wide in the community we care so much about and seek to encourage.

Ultimately, we must reach a point where software security is synonymous with software quality; there is simply too much at stake these days to suggest otherwise. And with this partnership, I believe we can get developers actually excited about secure development. A thriving environment of security awareness and a positive culture is key, and I couldn't think of any other company more perfect to get us there.

Watch this space: the security conversation is about to dramatically shift left.

Device encryption is the process of encrypting all the data on the Android device. Once this is enabled for an Android device, all user-created data is immediately encrypted before it is written to the storage. This protects the data so that even if any unauthorized party tries to access the data, they wont be able to read it. This is an especially good feature for smartphone devices, since these are carried around by the user and more prone to loss or theft than other computing devices. Any curious finder or thief can not access the data unless he can unlock the phone.

Android has two types of device encryption: full-disk encryption and file-based encryption.

Full-disk encryption

Full-disk encryption was introduced in API level 19 (Android 4.4 KitKat), but the new features in API level 21 (Android 5.0 Lollipop) really kickstarted its use. Full-disk encryption uses a single key to protect the whole devices userdata partition. The key is protected with the users credentials and they must be provided upon boot before any part of the disk is accessible.

This is great for security but it also means that most of the functionality of the device is unavailable until the user enters their credentials. This means when the device is rebooted but not unlocked, some features like alarms cannot operate, services are unavailable and phones cannot receive calls. For this reason the second encryption mode was created.

File-based encryption

File-based encryption, the second mode of device encryption, has been available since API level 24 (Android 7.0 Nougat). In this mode, different files are encrypted with different keys that can be unlocked independently. With this encryption mode came the Direct Boot mode, which allows encrypted devices to boot straight to the lock screen, enabling the previously missing features before unlocking the device.

The Direct Boot allows apps to operate within a limited context before the device is unlocked. This way, they can still function as expected without compromising the user information. In order to provide this functionality, the Android device needs two storage locations:

1. Credential Encrypted storage. Default storage location, only available after the user has unlocked the device.
2. Device Encrypted storage. Available in Direct Boot mode, and after the user has unlocked the device.

If your app needs to access data while running in Direct Boot mode, it should use the Device Encrypted storage. But be aware of the security implications! Device Encrypted Storage should not be used to store any sensitive data! The Device Encrypted storage is encrypted with a key that is available as soon as the device has successfully booted. Any data that is only meant be accessed by the user should be saved in the default location, the Credential Encrypted storage.

If you want to learn more about what encryption is or why it is important, check out the video on the Secure Code Warrior portal. Or you can try to test your knowledge on encryption by playing some challenges.

Need a step-by-step guide for your device? Check out this article from Bill Hess at Pixel Privacy.

I hope you learned something new. See you next week!

Credential encrypted storage, which is the default storage location and only available after the user has unlocked the device.

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

De nouvelles recherches explorent les avantages d'une formation de qualité en matière de sécurité.

Quels sont les impacts potentiels d'une formation au code sécurisé de qualité pour votre organisation, et serait-ce un investissement rentable ? Pour trouver des réponses, examinons quelques informations tirées d'une étude récente sur l'attitude des développeurs à l'égard du codage sécurisé, des pratiques de code sécurisées et des opérations de sécurité, menée par Secure Code Warrior avec Evans Data Corp*.
‍

Lorsqu'on a demandé aux développeurs et à leurs responsables comment la formation avait modifié leur façon de coder, chaque cohorte a répondu légèrement différemment. Ces différences étaient conformes à la façon dont ils abordent leur travail et à leur rôle dans le cycle de vie du développement logiciel. Dans l'ensemble, cependant, le thème sous-jacent est que l'impact d'une formation au code sécurisé de qualité est extrêmement positif.

55 % des développeurs ont indiqué qu'une bonne formation leur avait permis de renforcer leur confiance dans leurs techniques de codage, tandis que 53 % ont déclaré qu'une bonne formation leur avait permis d'être plus prudents lorsqu'ils déboguaient et testaient leur propre code.

Plus important encore, 53 % pensent être devenus plus attentifs à la sécurité lors de l'écriture de leur code, ce qui a permis de réduire le nombre de vulnérabilités et de retouches.

Les responsables obtiennent des versions logicielles plus rapides

Alors que 43 % des responsables reconnaissent que la formation au code sécurisé a aidé leur organisation à être plus prudente lors du débogage et du test de leur code, les deux principaux changements reflètent les responsabilités managériales. 47 % ont indiqué qu'une formation de qualité leur avait permis d'être plus sélectifs dans les choix d'outils offrant plus de sécurité. 44 % ont indiqué que la formation et les techniques de codage sécurisé avaient permis de gagner du temps et d'accélérer les versions logicielles.

L'influence du codage sécurisé sur la productivité

Lorsqu'il s'agit d'augmenter la productivité, les pratiques de codage sécurisées peuvent avoir un effet puissant. Lorsqu'on leur a demandé comment le codage sécurisé pouvait contribuer à améliorer la productivité, plus de 63 % des développeurs ont indiqué que l'écriture de code sécurisé et de qualité réduisait les retouches en évitant les vulnérabilités récurrentes. 70 % des développeurs affirment qu'une formation de qualité pourrait éliminer les erreurs qui, par la suite, entraînent des retouches ou des correctifs.

L'impact du codage sécurisé sur le cycle de vie du développement

Au fur et à mesure que les développeurs et leurs responsables intègrent des pratiques de codage sécurisées dans leurs cycles de développement, les impacts réels de leur formation peuvent être mesurés.

Il semble que les améliorations soient généralisées, améliorant la productivité dès le début du SDLC. Plus de la moitié des développeurs interrogés affirment qu'une formation de qualité a amélioré la productivité en matière de conception, de codage, de débogage et de tests d'applications.

La phase de débogage et de test est la plus touchée, 56 % des développeurs déclarant être devenus plus productifs grâce à ces activités. Bien que de meilleurs outils d'analyse et de test aient pu raccourcir cette phase de développement, les pratiques de codage sécurisé favorisent l'utilisation et la réutilisation de code approuvé dont il est prouvé qu'il ne présente aucune faille de sécurité, ainsi qu'une approche axée sur la sécurité lors de la conception des applications. En « repartant à gauche » du cycle de développement avec leur approche de la sécurité, les développeurs peuvent gagner du temps pendant la phase de débogage.

Le déploiement, qui se situe plus en aval, est moins impacté, même si 44 % des développeurs révèlent qu'ils sont devenus plus productifs même en cours de déploiement. Cela est dû à l'augmentation de la vitesse de publication associée aux pratiques de codage sécurisées.

Une voie éprouvée vers une meilleure formation

Il ne fait aucun doute qu'une formation au code sécurisé de qualité présente de nombreux avantages. La question qui se pose est la suivante : comment évaluez-vous la qualité de la formation au code sécurisé ?

Pour trouver la réponse, nous avons demandé aux développeurs ce qu'ils souhaitaient. 75 % des développeurs ont préféré une formation structurée en cours d'emploi. Ils préfèrent la méthode de l'apprentissage par la pratique à la corvée de l'apprentissage statique basé sur la théorie. Les développeurs sont en première ligne lorsqu'il s'agit de stopper les vulnérabilités. Par conséquent, ils souhaitent une formation axée sur des applications pratiques, ce qui fait cruellement défaut à la plupart des programmes de formation actuels.

En tant que champion du changement en matière de codage sécurisé, Secure Code Warrior adopte une approche dirigée par l'homme pour vous aider à créer une défense dirigée par l'homme. Notre plateforme d'apprentissage éprouvée propose des contenus de formation contextuels et pratiques sur Plus de 50 langages : frameworks, avec des défis similaires à ceux auxquels les développeurs sont confrontés dans le monde réel. Tout cela permet de réduire les coûts et les délais de publication en prévenant les vulnérabilités avant qu'elles ne deviennent l'actualité de demain.

Si vous souhaitez voir l'impact potentiel sur vos équipes et leur capacité à fournir du code sécurisé plus rapidement, réservez une démo dès maintenant.

Lors du développement pour mobile, les applications doivent souvent demander certaines autorisations au système. Ils peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou de pouvoir envoyer des SMS. Toutes les autorisations mentionnées ci-dessus sont des autorisations de plate-forme, définies par le framework Android.

Mais dans certains cas, cela ne suffit pas et l'application doit définir sa propre autorisation personnalisée. Je vais utiliser notre propre entreprise comme exemple. Secure Code Warrior peut 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. Et nous aimerions autoriser une autre application de formation à la sécurité, par exemple DevTrainer, à utiliser ces données si l'utilisateur l'autorise. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les sache, mais la SCWapp ne doit pas complètement les cacher et les protéger car cela peut être utile. Nous souhaitons donc permettre à l'utilisateur d'en avoir le contrôle. C'est là qu'entrent en jeu les autorisations personnalisées.

Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il souhaite 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, certains comportements peu intuitifs entourent les autorisations personnalisées, ce qui les rend risquées du point de vue de la sécurité. Des autorisations concrètes et personnalisées peuvent être définies par n'importe quelle application à tout moment, et « le premier gagne », et cette stratégie a des conséquences.

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

1. Appli SCW: l'application qui définit une autorisation personnalisée et défend un composant à l'aide de cette autorisation.

2. DevTrainer: cette application définit la même autorisation que SCWapp et déclare à l'utilisateur qu'il souhaite détenir cette autorisation.

Il s'agit d'un scénario courant appelé Peer Apps Case. Si l'application DevTrainer n'était qu'un plugin pour SCWapp, elle n'aurait pas à définir l'autorisation personnalisée. Dans ce cas, l'hypothèse est que SCWapp serait installé 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, l'autorisation n'est pas accordée rétroactivement à DevTrainer. Les tentatives de l'application DevTrainer pour utiliser le composant sécurisé échoueront.

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

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'en a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.

Cela devient encore plus délicat. 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 ramène le niveau d'autorisation à la normale, les futures applications qui demanderont cette autorisation 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 github cwac-security.

La stratégie du « premier gagnant » a des conséquences dangereuses et ne pas connaître son comportement peut amener le développeur à prendre des décisions de sécurité sur la base d'entrées non fiables et à autoriser des applications indésirables à accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter de prendre des décisions de sécurité via une saisie non fiable, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais depuis ce jour, plus de 22 % Si des appareils Android utilisent toujours une version inférieure d'Android, il est important d'atténuer les risques liés au comportement initial de votre application. Vérifiez si l'autorisation a déjà été définie lors de la première exécution de votre application et, le cas échéant, prenez les mesures appropriées pour résoudre les risques de sécurité.

Bonne chance pour coder, et à la semaine prochaine !

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

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

27th Jan 2018. Secure Code Warrior's birthday falls one day after Australia Day. I realised while contemplating another fantastic year that I actually have two three year olds in my life, one business and one human... with remarkable similarities:

• They are trouble to put to bed in the evening without a proper routine

"Just reading that last email which just came in ... or wait, I quickly need to sync on the phone with our team in the US... or this proposal really needs to go out by tonight. Damn. It's past midnight again."

• They make you so proud when they achieve something

Even if you didn't sleep properly for 3 weeks, had no time to exercise or just had to clean-up a mess... but your pilot demonstrated the impact on security skills of developers and the customer is happy to commit working with us for another three years! BOOM! Energy peaks. And cakes everywhere. Suddenly, the lack of sleep doesn't matter so much.

• They grow up so quickly

Gone are the days where you could sneak out with the team to Bali and work from the beach house on the next features of the platform. Our start-up has grown between 4-6 fold in the last year (depending if you measure staff, customers or revenue) with engineering in Sydney (AU) and Bruges (BE) and sales and marketing in USA, Europe and Australia. I remember a year ago when I was really excited having one of the big Australian banks as a customer. Today, we're working with 10 of the top 100 global financial institutions as well as some of the key telecom and technology companies that are building the next generation of online services (note: I am still really proud of the Aussie banks, who were our first customers!).

We've grown up so fast on so many fronts but one of the key milestones last year was actually defining a vision for our company. In the early years, we were so focused on building, executing and making sure there was cash that we often forget to stop and reflect on exactly what we want to achieve. The more people join Secure Code Warrior and the more customers we brought on board, the more important it was to have a consistent vision and understand where we are going. We did that in 2017.

Another key milestone was technology related. We realised early on that building the skills of a developer is only the start of the secure coding journey. They need tools around them to make security embedded and easy rather than an afterthought or something that you think of when you're done writing the code. No, security needs to be built from the start, while writing code.

Our team has worked very hard on writing security coaching plug-ins for the most common IDE's (IntelliJ, Visual Studio, Android Studio to name a few) that will actually help the developer to write more secure code. Not by solely pointing out potential security weaknesses but to really be a coach and jumping in when developers are writing code that is not aligned with leading practices in security. The security coaching plug-in is called Sensei and it truly allows a developer to be trained on-the-spot (micro-learning) and in some cases, it will offer an auto-correct option to fix code instantly.

I am really excited about what the next 12 months are going to bring. We are already seeing that software security is no longer just the concern of the biggest developer-heavy companies like banks, telecom or technology companies. Organisations of all types continue to be compromised by software weaknesses and although SQL injection might finally die, there are a range of other ones waiting to take its place.

There is now a heightened expectation from customers, markets and boards across all industries that companies protect the security of their code. Compliance will keep pushing organisations in this direction too (eg. GDPR for anyone doing business in Europe, Data Breach laws coming in Australia etc.)

This means I am confident our SCW platform will continue its rapid growth across the world and across new industries. That's good news for our business of course, but it is also helping my team to deliver on our vision, which I believe is very worthwhile for the software era that we live in.

Developers using our tools really can and are taking a more proactive role in the security of their company. They have the skills and tools to write secure code, to be the first line of defence for their company.

I feel the same way about being a parent of a three year old and CEO of Secure Code Warrior: every year is better than the last. I can't wait to see how the four year old develops!

Our vision is to empower developers to be the first line of defence in their organisation by making security highly visible and providing them with the skills and tools to write secure code from the beginning.

Meet developers where they are 

Organizations looking to DevSecOps for faster, more secure releases know the importance of optimizing developer productivity with an integrated technology stack. Secure Code Warrior's software integrations empower your developers with secure development resources integrated in the tools they use every day, such as GitHub, Jira, and more. 

Secure Code Warrior ensures your secure code program is built directly into your preferred products and developers’ workflows to enable just-in-time remediation, as well as stickier learning outcomes.

Reduce vulnerabilities with faster remediation

Finding and fixing a vulnerability can be like solving a large puzzle without some of the pieces and the helpful cover art, which sometimes can take days, weeks, or even months to complete with a robust solution. This can be particularly tough for developers when they may not know how to fix the problem, either because they have never encountered the problem before, or because they are hesitant to deploy an untested or unverified solution.

The average Mean Time to Remediation (MTTR) for a located vulnerability across a full stack, according to the EdgeScan 2022 Vulnerability Statistic Report was 57.5 days (EdgeScan2022 Vulnerability Statistics Report).

This is a critical window in which valuable data could be compromised, trust is lost, and valuable developer productivity is wasted - decreasing your code release velocity and ultimately accumulating more tech debt with quick fixes or sloppy patchwork because of a lack of knowledge or confidence in the solutions deployed.

Secure Code Warrior’s integrations offer trusted remediation advice, enabling developers to resolve security bugs confidently while staying in the flow. By empowering developers to own remediation at the source, AppSec can focus on risk monitoring and strengthening the security posture of the organization. 

With contextual secure coding guidance embedded in work items, developers get immediate help to learn more about detected vulnerabilities and how to fix them - thus reducing MTTR, in addition to offering valuable, sticky learning outcomes that proactively reduce vulnerabilities at the source- the code.

Scale-up learning across your teams 

SCORM LMS integration

SCORM means Sharable Content Object Reference Model and is an international standard for e-courses. If your course is published in the SCORM format, you can be sure that almost any learning management system (LMS) will recognize it. With SCORM, you can easily manage a secure code training program alongside your other training platforms in one place.

Check for proficiency before shipping code 

Secure Code Warrior Connector for Okta Workflows helps to prevent insecure code from being introduced to your codebase with the power of a security-proficiency check that can be built into your flow. When working on codebases, such as in a GitHub repository, you can set required lessons and assessments as qualifiers for coding in the base. This empowers your leaders to make sure each developer is ready to work in the relevant codebase, helping level up the security posture of the entire organization. 

Introduce security into the entire software development life cycle by ensuring that each individual developer has achieved the necessary secure coding skills to be granted repo access to commit code. This integration will ensure that developers are learning about the latest security practices through SCW’s highly engaging platform and that some of the burdens of manual code reviews are reduced, freeing up engineering hours to ship more functionality without sacrificing quality.

Learn more about Okta + SCW or see the Demo here. 

Just-in-time support when committing code

SCW for GitHub enables contextual training inside GitHub workflows either in the SARIF files or directly within the issues and pull requests they are working on. This gives developers access to knowledge when they need it most in order to help them ship quality code faster. This integration doesn’t just enable a patch that is often applied without understanding. It continuously reinforces good, secure coding patterns to enable fast recognition of vulnerable code. 

Learn more about SCW+GitHub or see the Demo

Actionable secure coding guidance integrated inside GitLab embeds highly relevant Secure Code Warrior training links to the Vulnerability Details section of vulnerability reports. This ultimately helps to reduce the time gap between learning and application of knowledge to ensure future usage by enabling this integration. For example, if the vulnerability scanners detected a Cross-Site Request Forgery (CSRF) in the application code, the vulnerability detail would be updated with the relevant training link.

“By offering Secure Code Warrior’s extensive contextual learning across secure coding in our platform, we’ll enable developers to embrace security-first from the outset and not only save them time but also help them develop new skills.” - Nima Badiey, VP at GitLab

Learn more about SCW + GitLab

Synopsys Seeker integration embeds Secure Code Warrior resources, videos, and training links to vulnerability findings within Seeker. This ensures compliance with industry standards and regulations with micro-learning that identifies and resolves vulnerabilities with easily accessible training guidance within Seeker. 

Learn more about Synopsys + SCW

Help inside a ticket when you need it now 

Stop just finding security flaws, get help fixing them with Secure Code Warrior for Jira. Developers get contextual training right inside their Jira Issue Tracker, giving developers access to knowledge when they need it most in order to help them ship quality code faster. Secure Code Warrior for Jira detects these issue details and gives developers an opportunity to learn how to fix these issues - by accessing specific training videos within the environment that they are familiar with. Through contextual micro-learning, development teams can reduce vulnerabilities within the entire codebase, and stay on top of it by tracking and reporting via Jira.

Learn more about SCW + Jira

Write secure code at speed

Secure Code Warrior’s tech stack integrations enable micro-learning and faster remediation with industry-trusted guidance and solutions for common vulnerabilities. 

• Training links are attached as comments in issues and pull requests so that the guidance is easily accessible when needed.

• Content is highly relevant and fetched based on Common Weakness Enumeration (CWE) or Open Web Application Security Project (OWASP) references. 

• Extensive coverage means that learning resources come from the world's leading collection of secure coding training. 

Common vulnerabilities, many of which have been known for decades, continue to persist within the SDLC because of reactive measures. Scanning tools and pentesting only find the problem, and often after the application is already in production. They are notoriously slow - surfacing multiple false positives and negatives requiring manual review - rarely addressing the cause of the issue or its source.

Empowering and enabling your developers with micro-learning and remediation advice inside their workflows helps them to catch security weaknesses earlier in the development process before they become expensive, or worse leaving vulnerabilities that can be exploited later. Secure Code Warrior integrations meet your developers where they work and not only help them find and fix vulnerabilities faster, but learn by doing from trusted resources and bite-sized guidance to enhance their skills and reinforce security as a critical component of the Software Development Life Cycle. 

Looking to learn more? 

• Watch our Product Talk webinars to learn about all our exciting integrations at SCW
• Check out the Demo for Okta 
• Watch the demo for GitHub
• Try Secure Code Warrior for Free 

A version of this article appeared in Cybersecurity Insiders. It has been updated and syndicated here.

‍

The adoption of artificial intelligence assistants, ranging from Large Language Model (LLM) code creators to sophisticated agentic AI agents, provides software developers with a wealth of benefits. Yet recent findings, underscored by a new MIT study, issue a warning: heavy reliance on AI might lead users to lose critical thinking skills.

Given a software landscape where AI-related security risks have grown in step with AI adoption, this loss of cognitive fitness could indeed lead to catastrophic outcomes. It is an ethical imperative for developers and organizations to proactively identify, understand, and mitigate security vulnerabilities early within the Software Development Lifecycle (SDLC). Those who neglect this duty, which, alarmingly, describes many organizations today, face an equally sharp rise in potential security threats, some of which are directly attributable to AI.

The debate is not whether to use AI, since the productivity and efficiency benefits are too great to dismiss. Instead, the real question is how to apply it most effectively: safeguarding security while maximizing output growth. And this is best done by security-proficient developers who deeply understand their code, no matter where it originated.

Over-reliance on AI risks cognitive decline

The study by MIT’s Media Lab, released in early June, tested the cognitive functions of 54 students from five Boston-area universities while they wrote an essay. The students were divided into three groups: those using a Large Language Model (LLM), those using search engines, and those going old school with no outside assistance. The research team used electroencephalography (EEG) to record the participants' brain activity and assess cognitive engagement and cognitive load. The team found that the old school, “brain-only” group exhibited the strongest, most wide-ranging neural activity, while those using search engines showed moderate activity, and those using an LLM (in this case, OpenAI’s ChatGPT-4) exhibited the least amount of brain activity.

This may not be particularly surprising—after all, when you enlist a tool to do your thinking for you, you are going to do less thinking. However, the study also revealed that LLM users had a weaker connection to their papers: 83% of students struggled to recall the content of their essays even just minutes after completion, and none of the participants could provide accurate quotes. A sense of author ownership was missing compared with the other groups. Brain-only participants not only had the highest sense of ownership and showed the broadest range of brain activity, but they also produced the most original papers. The LLM group’s results were more homogenous—and, in fact, were easily identified by judges as the work of AI.

From the developers' point of view, the key outcome is diminished critical thinking stemming from AI use. A single instance of relying on AI might not cause a loss of essential thinking skills, of course, but constant use over time can cause those skills to atrophy. The study suggests a way to help keep critical thinking alive while using AI—by having AI help the user rather than the user help AI—but the real emphasis must be on ensuring that developers have the security skills they need to build safe software and that they use those skills as a routine, essential part of their jobs.

Developer education: Essential for the AI-driven ecosystem

A study like MIT’s isn’t going to stop AI adoption, which is pushing forward across every sector. Stanford University’s 2025 AI Index Report found that 78% of organizations reported using AI in 2024, compared with 55% in 2023. That kind of growth is expected to continue. But increased use is mirrored by increased risk: The report found that AI-related cybersecurity incidents grew by 56% over the same time. 

Stanford’s report underscores the vital need for improved AI governance, as it also found that organizations are lax in implementing security safeguards. Although practically all organizations recognize the risks of AI, fewer than two-thirds are doing anything about it, leaving them vulnerable to a host of cybersecurity threats and potentially in violation of increasingly strict regulatory compliance requirements.

If the answer isn’t to stop using AI (which no one will do), it must be to use AI more safely and securely. The MIT study offers one helpful clue on how to go about that. In a fourth session of the study, researchers broke the LLM users into two groups: those who started the essay on their own before turning to ChatGPT for help, known in the study as the Brain-to-LLM group, and those who had ChatGPT work up a first draft before giving it their personal attention, known as the LLM-to-Brain group. The Brain-to-LLM group, which used AI tools to help rewrite an essay they had already drafted, showed higher recall and brain activity, with some areas similar to those of the search engine users. The LLM-to-Brain group, which allowed AI to initiate the essay, exhibited less coordinated neural activity and a bias toward using LLM vocabulary.

A Brain-to-LLM approach may help keep users’ brains a bit sharper, but developers also need the specific knowledge to write software securely and to critically evaluate AI-generated code for errors and security risks. They need to understand AI’s limitations, including its propensity to introduce security flaws such as vulnerabilities to prompt injection attacks.

This requires overhauling enterprise security programs to ensure a human-centric SDLC, in which developers receive effective, flexible, hands-on, and ongoing upskilling as part of an enterprise-wide security-first culture. Developers need to continuously sharpen their skills to stay abreast of rapidly evolving, sophisticated threats, particularly those driven by AI’s prominent role in software development. This protects against, for example, increasingly common prompt injection attacks. But for that protection to work, organizations need a developer-driven initiative to focus on secure design patterns and threat modeling.

Conclusion

When LLMs or agentic agents do the heavy lifting, users become passive bystanders. This can lead, the study’s authors said, to “weakened critical thinking skills, less deep understanding of the materials and less long-term memory formation.” A lower level of cognitive engagement can also lead to reduced decision-making skills. 

Organizations cannot afford a lack of critical thinking when it comes to cybersecurity. And because software flaws in highly distributed, cloud-based environments have become the top target of cyberattackers, cybersecurity starts with ensuring secure code, whether it is created by developers, AI assistants or agentic agents. For all of AI’s power, organizations more than ever need highly honed problem-solving and critical thinking skills. And that can’t be outsourced to AI.

The new AI capabilities of SCW Trust Agent provide the deep observability and control you need to confidently manage AI adoption in your SDLC without sacrificing security. Find out more.

It’s becoming increasingly clear that companies must embed Secure by Design principles into their product development processes–not just for compliance, but as a critical business requirement. The guidelines are in place for companies to identify and mitigate exploitable flaws in their products before introducing them to the market. Products built in accordance with these principles by organizations that treat these guidelines as a foundational pillar, rather than just an add-on, tend to remain ahead in this increasingly competitive market. 

But two years since the United States government’s Cybersecurity & Infrastructure Security Agency (CISA) released their Secure by Design guidelines, actual, real-world implementation is still an industry-wide puzzle we struggle to solve. We all know that these principles matter, but how can we effectively implement them at scale?

In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook. 

Discover some of the key findings:

• Most security practitioners and business leaders are on board with the idea and value of Secure by Design initiatives; however, it remains, in a way, open to interpretation, and there is no standard industry-wide approach for implementing it.

• Threat modeling isn’t just something to tick off the compliance checklist - it’s a critical, consistent practice that helps security-savvy developers and their AppSec counterparts stay ahead of risks before they become exploits. 

• The double-edged sword that is AI - AI is both a breakthrough and a potent security risk that significantly expands the attack surface. Its explosive growth introduces rapidly evolving risks that unskilled developers and under-resourced AppSec teams often struggle to mitigate.

The problem isn’t a lack of understanding of the importance of applying Secure by Design principles– if anything, the need for secure software has become a foundational need and a baseline expectation. What’s missing is a coordinated, scalable strategy to embed these principles across the software development lifecycle. 

We also seem to lack clear benchmarks or measurable outcomes for determining successful rollouts. Without these, teams are left guessing on whether their efforts are truly making an impact. For now, we seem to have a united battlefront, but no shared strategy. 

Secure by Design is essential and inevitable, and not just for high-compliance sectors. Developers must also be empowered, not burdened. When equipped with the right skills, tools and support, they inherently become not just builders – but defenders, embedding security where it matters most: at the source. 

Download now  and discover how your team can leverage powerful developer risk management strategies and precision measurement to drive a successful, unified Secure by Design initiative within the enterprise.

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

Selon un récent enquête réalisée par GitHub, plus de 90 % des développeurs américains utilisent des outils de codage basés sur l'IA, invoquant des avantages tels que des délais de traitement plus rapides, une résolution rapide des incidents et un environnement plus collaboratif, ce qui leur semble important. L'utilisation d'outils d'IA permet aux développeurs de déléguer des tâches de routine, ce qui leur permet de travailler sur des emplois plus créatifs qui profitent à leur entreprise et, ce n'est pas un hasard, de réduire les risques d'épuisement professionnel.

Cependant, des études ont également montré que les outils d'IA ont tendance à introduire des failles lors de l'écriture de code. UNE enquête réalisée par Snyk a constaté que même si 75,8 % des personnes interrogées ont déclaré que le code IA est plus sécurisé que le code humain, 56,4 % ont admis que l'IA posait parfois des problèmes de codage. Il est alarmant de constater que 80 % des personnes interrogées ont déclaré avoir contourné les politiques de sécurité des codes d'IA pendant le développement.

Depuis OpenAI Chat GPT lancée en novembre 2022, l'utilisation de modèles d'IA génératifs s'est répandue à une vitesse fulgurante tout au long du processus de développement de code dans les services financiers, comme elle l'a fait dans de nombreux autres domaines. L'émergence rapide d'autres modèles, tels que Copilote GitHub, Codex OpenAI, et un liste croissante d'autres, suggère que nous n'avons qu'une première idée 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 généré est sécurisé.

Les bugs de codage peuvent se propager rapidement

Qu'il soit créé par des développeurs humains ou par des modèles d'IA, le code va contiennent des erreurs. L'IA aidant à accélérer le développement de code pour répondre aux exigences toujours croissantes des environnements informatiques hautement distribués et basés sur le cloud, les risques que le code incorrect se propage largement avant d'être détecté pourraient augmenter.

Les modèles d'IA entraînés à écrire du code ingéreront des milliers d'exemples de code qui exécutent diverses tâches, puis ils pourront s'appuyer sur ces exemples pour créer leur propre code. Mais si les échantillons à partir desquels il fonctionne contiennent des failles ou des vulnérabilités, qu'elles aient été créées à l'origine par un humain ou une autre IA, le modèle pourrait transférer ces failles dans un nouvel environnement.

Considérant des recherches ont montré selon laquelle les modèles d'IA ne sont pas capables de reconnaître de manière fiable les failles du code qu'ils utilisent, il existe peu 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 plus tard, 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 l'écriture du code d'IA et servir de frein aux pratiques de codage non sécurisées et au code vulnérable. Mais pour cela, les développeurs doivent être parfaitement formés aux meilleures pratiques en matière d'écriture de code sécurisée afin de pouvoir identifier les erreurs de codage qu'une IA pourrait commettre et les corriger rapidement.

Les défis de la création et de la correction de codes d'IA

L'explosion soudaine de grands modèles de langage (LLM) tels que ChatGPT a été en quelque sorte une arme à double tranchant. D'un côté, les entreprises et les utilisateurs ordinaires ont constaté d'énormes gains de productivité grâce à l'utilisation de l'IA pour gérer des tâches fastidieuses, onéreuses ou difficiles. D'un autre côté, il existe de nombreux exemples de ce qui peut mal tourner lorsque l'on fait aveuglément confiance à l'IA pour gérer le travail.

Les modèles d'IA ont créé erreurs flagrantes, a fait preuve de partialité et a produit hallucinations pures et simples. Dans de nombreux cas, le problème était dû à des données de formation inadéquates ou irresponsables. La qualité de tout 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. Même dans ce cas, certaines erreurs seront commises.

L'utilisation de l'IA pour le codage se heurte à bon nombre des mêmes obstacles. Il a été démontré que le code généré par l'IA contient toute une série de failles, telles que des vulnérabilités liées au cross-site scripting et à l'injection de code, ainsi que des attaques spécifiques à l'IA et à l'apprentissage automatique (ML), telles que injection rapide. Les modèles d'IA fonctionnent également dans 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 une IA parvient à ses conclusions. Par conséquent, le modèle peut répéter les mêmes erreurs encore et encore. Les mêmes lacunes qui peuvent affecter l'écriture de code se répercutent également sur l'utilisation de l'IA pour correction du code et en respectant les exigences de conformité.

Le potentiel de failles créées ou répétées par les modèles d'IA a augmenté au point que les LLM disposent désormais de leur propre liste OWASP (Open Web Application Security Project) les dix principales vulnérabilités.

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

Les inquiétudes concernant les failles potentielles du code généré par l'IA pourraient inciter certaines organisations à réfléchir, ne serait-ce que brièvement, à l'idée 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. Le secteur des services financiers, pour sa part, a peu de chances de remettre 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 recherchent toujours un avantage concurrentiel.

L'essentiel est de mettre en œuvre des modèles d'IA de manière à minimiser les risques. Cela signifie avoir des développeurs sensibilisés à la sécurité et parfaitement formés 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 associant les moteurs d'IA et les développeurs humains dans le cadre d'un partenariat étroit, les développeurs ayant le dernier mot, les entreprises peuvent bénéficier des avantages 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 bénéfices des sociétés de services financiers, vous pouvez lire le nouveau guide Secure Code Warrior : Le guide ultime des tendances en matière de sécurité dans les services financiers.

‍

‍

Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur la cybersécurité, le paysage des menaces de plus en plus dangereuses, et pour savoir comment vous pouvez utiliser des technologies innovantes et des formations pour mieux protéger votre organisation et vos clients.

‍