In recent months, we’ve marveled at the quality of computer-generated faces, cat pictures, videos, essays, and even art. Artificial intelligence (AI) and machine learning (ML) have also quietly slipped into software development, with tools like GitHub Copilot, Tabnine, Polycode, és mások megteszi a következő logikus lépést: a meglévő kódautomatikus kiegészítést az AI-szteroidokon helyezi el. A macskaképekkel ellentétben azonban az alkalmazáskód eredete, minősége és biztonsága széles körű következményekkel járhat – és legalábbis a biztonság szempontjából a kutatások azt mutatják, hogy a kockázat valós.
Előzetes tudományos kutatás már kimutatta, hogy a GitHub Copilot gyakran generál biztonsági réseket tartalmazó kódot. A közelmúltban az Invicti biztonsági mérnöke, Kadir Arslan gyakorlati elemzése kimutatta ezt nem biztonságos kódjavaslatok a Copilot esetében továbbra is inkább a szabály, mint a kivétel. Arslan úgy találta, hogy sok gyakori feladatra csak az abszolút csupasz csontokat javasolták, gyakran a legalapvetőbb és legkevésbé biztonságos útvonalat választva, és ezek módosítás nélküli elfogadása működőképes, de sebezhető alkalmazásokat eredményezhet.
Egy olyan eszköz, mint a Copilot (tervezés szerint) az automatikus kiegészítés, amely nyílt forráskódra oktatott, hogy olyan kódrészleteket javasoljon, amelyek relevánsak lehetnek hasonló kontextusban. Ezáltal a javaslatok minősége és biztonsága szorosan összefügg a képzési készlet minőségével és biztonságával. A nagyobb kérdések tehát nem a Copilotra vagy más konkrét eszközre vonatkoznak, hanem általában az AI által generált szoftverkódra.
It’s reasonable to assume Copilot is only the tip of the spear and that similar generators will become commonplace in the years ahead. This means we, the technology industry, need to start asking how such code is being generated, how it’s used, and who will take responsibility when things go wrong.
Satnav szindróma
Traditional code autocompletion that looks up function definitions to complete function names and remind you what arguments you need is a massive time-saver. Because these suggestions are merely a shortcut to looking up the docs for yourself, we’ve learned to implicitly trust whatever the IDE suggests. Once an AI-powered tool comes in, its suggestions are no longer guaranteed to be correct — but they still feel friendly and trustworthy, so they are more likely to be accepted.
Especially for less experienced developers, the convenience of getting a free block of code encourages a shift of mindset from, “Is this code close enough to what I would write” to, “How can I tweak this code so it works for me.”
GitHub very clearly states that Copilot suggestions should always be carefully analyzed, reviewed, and tested, but human nature dictates that even subpar code will occasionally make it into production. It’s a bit like driving while looking more at your GPS than the road.
Az ellátási lánc biztonsági problémái
A Log4j biztonsági válság nemrégiben a szoftver-ellátási lánc biztonságát és különösen a nyílt forráskódú biztonságot helyezte a figyelem középpontjába Fehér Ház feljegyzés a biztonságos szoftverfejlesztésről és egy új törvényjavaslat a nyílt forráskódú biztonság javításáról. Ezekkel és más kezdeményezésekkel lehetséges, hogy az alkalmazásokban lévő nyílt forráskódot hamarosan be kell írni egy szoftverjegyzékbe (SBOM), ami csak akkor lehetséges, ha tudatosan szerepeltet egy adott függőséget. A szoftverösszetétel-elemző (SCA) eszközök szintén erre a tudásra támaszkodnak az elavult vagy sebezhető nyílt forráskódú összetevők észlelésében és megjelölésében.
But what if your application includes AI-generated code that, ultimately, originates from an open source training set? Theoretically, if even one substantial suggestion is identical to existing code and accepted as-is, you could have open source code in your software but not in your SBOM. This could lead to compliance issues, not to mention the potential for liability if the code turns out to be insecure and results in a breach — and SCA won’t help you, as it can only find vulnerable dependencies, not vulnerabilities in your own code.
Engedélyezési és forrásmegjelölési buktatók
Continuing that train of thought, to use open source code, you need to comply with its licensing terms. Depending on the specific open source license, you will at least need to provide attribution or sometimes release your own code as open source. Some licenses forbid commercial use altogether. Whatever the license, you need to know where the code came from and how it’s licensed.
Again, what if you have AI-generated code in your application that happens to be identical to existing open source code? If you had an audit, would it find that you are using code without the required attribution? Or maybe you need to open source some of your commercial code to remain compliant? Perhaps that’s not yet a realistic risk with current tools, but these are the kind of questions we should all be asking today, not in 10 years’ time. (And to be clear, GitHub Copilot does have an optional filter to block suggestions that match existing code to minimize supply chain risks.)
Mélyebb biztonsági vonatkozások
Going back to security, an AI/ML model is only as good (and as bad) as its training set. We’ve seen that in the past - például azokban az esetekben faji elfogultságot mutató arcfelismerő algoritmusok mert az adatok alapján képezték ki őket. Tehát, ha van olyan kutatásunk, amely azt mutatja, hogy egy kódgenerátor gyakran a biztonság figyelembevétele nélkül állít elő javaslatokat, akkor arra következtethetünk, hogy a tanulókészlete (vagyis nyilvánosan elérhető kódja) ilyen volt. És mi van akkor, ha a nem biztonságos AI által generált kód visszacsatol a kódbázisba? Biztosak lehetnek valaha a javaslatok?
The security questions don’t stop there. If AI-based code generators gain popularity and start to account for a meaningful proportion of new code, it’s likely somebody will try to attack them. It’s already possible to fool AI image recognition by poisoning its learning set. Sooner or later, malicious actors will try to put uniquely vulnerable code in public repositories in the hope that it comes up in suggestions and eventually ends up in a production application, opening it up to an easy attack.
És mi a helyzet a monokultúrával? Ha több alkalmazás ugyanazt a rendkívül sérülékeny javaslatot használja, függetlenül annak eredetétől, akkor sebezhetőségi járványokat vagy akár mesterséges intelligencia-specifikus sebezhetőséget is vizsgálhatunk.
Tartsa szemmel az AI-t
Some of these scenarios may seem far-fetched today, but they are all things that we in the tech industry need to discuss. Again, GitHub Copilot is in the spotlight only because it currently leads the way, and GitHub provides clear warnings about the caveats of AI-generated suggestions. As with autocomplete on your phone or route suggestions in your satnav, they are only hints to make our lives easier, and it’s up to us to take them or leave them.
With their potential to exponentially improve development efficiency, AI-based code generators are likely to become a permanent part of the software world. In terms of application security, though, this is yet another source of potentially vulnerable code that needs to pass rigorous security testing before being allowed into production. We’re looking at a brand new way to slip vulnerabilities (and potentially unchecked dependencies) directly into your first-party code, so it makes sense to treat AI-augmented codebases as untrusted until tested — and that means testing everything as often as you can.
Even relatively transparent ML solutions like Copilot already raise some legal and ethical questions, not to mention security concerns. But just imagine that one day, some new tool starts generating code that works perfectly and passes security tests, except for one tiny detail: Nobody knows how it works. That’s when it’s time to panic.
