In the front, GPT-4 is used to audit some codes for vulnerabilities, and later, GPT-3 is used to compare the git repository. The final result is only for your reference in chatgpt to analyze various codes. There is a problem of false positives, which cannot be ruled out due to problems with my training model. You are welcome to leave a message about the false positive results, and I will follow up and deal with them as soon as possible~
If you want to see more comprehensive content, please follow me first and send a private message. I will write a more comprehensive analysis report of GPT-4 on a certain code based on your feedback.
foreword
GPT-3 found 213 security vulnerabilities in this git repository. In contrast, the best commercial tools on the market found only 99 security vulnerabilities. Although commercial tools provide context in a more structured format, after manually reviewing a random sample of 99/213 vulnerabilities detected by GPT-3, 4 were false positives. Everyone knows that code audits have false positives as a routine operation.
The results of the proportion of various script vulnerabilities are as follows:
The overall proportion of the number of analyzed vulnerabilities:
Introduction
ChatGPT has become the new favorite of the internet in recent years, and the cybersecurity industry, long skeptical of the potential impact of modern artificial intelligence, seems to be taking note, fearing that it could be abused by hackers with limited resources and zero technical knowledge .
At present, the field of artificial intelligence and machine learning has made great developments, which has opened up a new field of possibility - AI-based code analysis. How to use AI models to detect security vulnerabilities in code is of particular interest.
In this article, OpenAI's GPT-4 is used to analyze part of the code. At the end of the article, how does GPT-3 find security vulnerabilities in a code repository containing 129 vulnerable files. If you are interested, I will update it for you individually!
how to run
GPT-4 uses the Plus member version, which has the same configuration as the official website, and can handle long codes. (PS: If you have a friend who needs to register as a PLus member, please leave a message in private message, we will provide you with a nanny-level tutorial and invitation code, and you can purchase at a discount~)
The GPT-3 variant (text-davinci-003) has a context window of 4000 tokens, roughly 3000 English words. This means it can handle requests for at most a few hundred lines of code, not an entire codebase at once.
To solve this problem, only single files can be scanned with GPT-3. This means that it is difficult for GPT-3 to find security holes caused by the interaction of multiple code files unless enough prompt words are used to guide it. Especially when the source code uses common libraries like express.js, Flask, Python standard library, C standard library, etc. Maybe GPT-3 has related records. In the code analyzed in this paper, GPT-3 has relevant records for import libraries and can accurately detect security vulnerabilities without checking the code of any import libraries.
To be fair, I suspect that many existing commercial vulnerability scanning tools don't actually examine the code of imported libraries when doing static analysis, so this isn't too different from how some tools on the market work.
Each folder in the analyzed code repository is named after a type of security vulnerability and contains files with sample code containing one or more vulnerabilities. Some of these files contain trivial code, but many are the same code snippets you might encounter in a production codebase (note: they're still snippets though, and thus lack the context of the larger codebase). The README.md of each folder in the repository contains GPT-3's analysis of security vulnerabilities for all files in that folder.
Vulnerable codebase used:
https://github.com/chris-koch-penn/gpt3_security_vulnerability_scanner
At the beginning, I used GPT-4 analysis, and the following code will be compared with GPT-3.
1》Code injection vulnerability detection
PHP code snippet 1 (tarlogic-ex2.php):
Test results:
There is a loophole in this code, that is, remote code execution can be realized through the unserialize function of PHP. The specific reasons are as follows:
In the code, we can see that the __destruct() method of the entry class calls $this->awesome->flag(). The __destruct() method is automatically executed when a PHP object is destroyed.
The unserialize() function is used at the end of the code, which converts a serialized string back into a PHP value. In this example, the user can enter a serialized string via command line arguments.
By constructing a serialized string, an attacker can create an instance of the entry class and point its awesome property to an instance of the GiveFlag class. In this way, when the instance of the entry class is destroyed, the __destruct() method will execute the flag() method of the GiveFlag class, and then execute the innocent() method of the GiveFlag class. The innocent() method of the GiveFlag class opens the "flag.txt" file and reads its contents. This allows an attacker to trigger code execution by entering a maliciously crafted serialized string to obtain the contents of the "flag.txt" file.
To fix this vulnerability, the following points can be considered:
Avoid using the unserialize() function with untrusted data. Other methods such as JSON can be used to transfer and parse the data.
Be especially careful with potentially dangerous magic methods such as __destruct(). Make sure that no security risks are introduced when using these methods.
The result is still very detailed.
2"Flask deserialization vulnerability
Python code (pickle2.py):
GPT-4's ability to analyze long codes:
from __future__ import unicode_literals
from flask import Flask, request, make_response, redirect, url_for, session
from flask import render_template, flash, redirect, url_for, request
from werkzeug.security import safe_str_cmp
from base64 import b64decode as b64d
from base64 import b64encode as b64e
from hashlib import sha256
from cStringIO import StringIO
import random
import string
import os
import sys
import subprocess
import commands
import pickle
import cPickle
import marshal
import os.path
import filecmp
import glob
import linecache
import shutil
import dircache
import io
import timeit
import popen2
import code
import codeop
import pty
import posixfile
SECRET_KEY = 'you will never guess'
if not os.path.exists('.secret'):
with open(".secret", "w") as f:
secret = ''.join(random.choice(string.ascii_letters + string.digits)
for x in range(4))
f.write(secret)
with open(".secret", "r") as f:
cookie_secret = f.read().strip()
app = Flask(__name__)
app.config.from_object(__name__)
black_type_list = [eval, execfile, compile, open, file, os.system, os.popen, os.popen2, os.popen3, os.popen4, os.fdopen, os.tmpfile, os.fchmod, os.fchown, os.open, os.openpty, os.read, os.pipe, os.chdir, os.fchdir, os.chroot, os.chmod, os.chown, os.link, os.lchown, os.listdir, os.lstat, os.mkfifo, os.mknod, os.access, os.mkdir, os.makedirs, os.readlink, os.remove, os.removedirs, os.rename, os.renames, os.rmdir, os.tempnam, os.tmpnam, os.unlink, os.walk, os.execl, os.execle, os.execlp, os.execv, os.execve, os.dup, os.dup2, os.execvp, os.execvpe, os.fork, os.forkpty, os.kill, os.spawnl, os.spawnle, os.spawnlp, os.spawnlpe,
os.spawnv, os.spawnve, os.spawnvp, os.spawnvpe, pickle.load, pickle.loads, cPickle.load, cPickle.loads, subprocess.call, subprocess.check_call, subprocess.check_output, subprocess.Popen, commands.getstatusoutput, commands.getoutput, commands.getstatus, glob.glob, linecache.getline, shutil.copyfileobj, shutil.copyfile, shutil.copy, shutil.copy2, shutil.move, shutil.make_archive, dircache.listdir, dircache.opendir, io.open, popen2.popen2, popen2.popen3, popen2.popen4, timeit.timeit, timeit.repeat, sys.call_tracing, code.interact, code.compile_command, codeop.compile_command, pty.spawn, posixfile.open, posixfile.fileopen]
@app.before_request
def count():
session['cnt'] = 0
@app.route('/')
def home():
remembered_str = 'Hello, here\'s what we remember for you. And you can change, delete or extend it.'
new_str = 'Hello fellow zombie, have you found a tasty brain and want to remember where? Go right here and enter it:'
location = getlocation()
if location == False:
return redirect(url_for("clear"))
return render_template('index.html', txt=remembered_str, location=location)
@app.route('/clear')
def clear():
flash("Reminder cleared!")
response = redirect(url_for('home'))
response.set_cookie('location', max_age=0)
return response
@app.route('/reminder', methods=['POST', 'GET'])
def reminder():
if request.method == 'POST':
location = request.form["reminder"]
if location == '':
flash("Message cleared, tell us when you have found more brains.")
else:
flash("We will remember where you find your brains.")
location = b64e(pickle.dumps(location))
cookie = make_cookie(location, cookie_secret)
response = redirect(url_for('home'))
response.set_cookie('location', cookie)
return response
location = getlocation()
if location == False:
return redirect(url_for("clear"))
return render_template('reminder.html')
class FilterException(Exception):
def __init__(self, value):
super(FilterException, self).__init__(
'The callable object {value} is not allowed'.format(value=str(value)))
class TimesException(Exception):
def __init__(self):
super(TimesException, self).__init__(
'Call func too many times!')
def _hook_call(func):
def wrapper(*args, **kwargs):
session['cnt'] += 1
print session['cnt']
print args[0].stack
for i in args[0].stack:
if i in black_type_list:
raise FilterException(args[0].stack[-2])
if session['cnt'] > 4:
raise TimesException()
return func(*args, **kwargs)
return wrapper
def loads(strs):
reload(pickle)
files = StringIO(strs)
unpkler = pickle.Unpickler(files)
unpkler.dispatch[pickle.REDUCE] = _hook_call(
unpkler.dispatch[pickle.REDUCE])
return unpkler.load()
def getlocation():
cookie = request.cookies.get('location')
if not cookie:
return ''
(digest, location) = cookie.split("!")
if not safe_str_cmp(calc_digest(location, cookie_secret), digest):
flash("Hey! This is not a valid cookie! Leave me alone.")
return False
location = loads(b64d(location))
return location
def make_cookie(location, secret):
return "%s!%s" % (calc_digest(location, secret), location)
def calc_digest(location, secret):
return sha256("%s%s" % (location, secret)).hexdigest()
if __name__ == '__main__':
app.run(host="0.0.0.0", port=5051)Test results:
This Python code uses the Flask framework to implement a web application where users can set, get, and delete reminders. However, there are some security issues in the code:
The code uses Python's pickle module to serialize and deserialize user-entered data. 1. Pickle has known security risks, especially when dealing with untrusted data. An attacker may execute arbitrary code by constructing malicious pickle data. Although the _hook_call() function is used in the code to control pickle.loads() to a certain degree of security, it still cannot guarantee absolute security. A safer alternative such as JSON is recommended.
2. A static key named SECRET_KEY is used in the code, which may cause security risks. For increased security, consider using a stronger key generation strategy and changing keys periodically.
3. Use sha256 for digest calculation. Although it has not been proven to be unsafe at present, in order to improve security, you can consider using a more secure hash algorithm, such as bcrypt.
4. Use unsafe functions, such as eval, execfile and os.system. Although a black_type_list is defined in the code to limit the use of these dangerous functions, in actual development, you should try to avoid using these functions with potential security risks.
5. The code sets host to "0.0.0.0" in app.run(), which means the app will listen on all available network interfaces. In a production environment, this could lead to potential security issues. It is recommended to use "0.0.0.0" only in the development environment, and a specific IP address or domain name should be used in the production environment.
In summary, this code has certain security risks. In practical applications, it is necessary to fix these problems and pay attention to other aspects of security, such as HTTPS connection, access control, etc.
The analyst given is much more comprehensive than GPT-3.5, and the results of GPT-3.5 can be compared.
3 "Command injection vulnerability detection
PHP code 2:
<?php
$rootUname = $_GET['rootUname'];
$array = array();
/* check PHP Safe_Mode is off /
if (ini_get('safe_mode')) {
$array['phpSafeMode'] = '<strong><font class="bad">Fail - php safe mode is on - turn it off before you proceed with the installation</strong></font>br/>';
} else {
$array['phpSafeMode'] = '<strong><font class="Good">Pass - php safe mode is off</strong></font><br/>';
}
/ Test root account details */
$rootTestCmd1 = 'sudo -S -u ' . $rootUname . ' chmod 0777 /home 2>&1';
exec($rootTestCmd1, $cmdOutput, $err);
$homeDirPerms = substr(sprintf('%o', fileperms('/home')), -4);
if ($homeDirPerms == '0777') {
$array['rootDetails'] = '<strong><font class="Good">Pass - root account details are good </strong></font><br/>';
} else {
$array['rootDetails'] = '<strong><font class="bad">The root details provided have not passed: ' . $cmdOutput[0] . '</strong></font><br/>';
}
// reset /home dir permissions
$rootTestCmd2 = 'sudo -S -u ' . $rootUname . ' chmod 0755 /home 2>&1';
exec($rootTestCmd2, $cmdOutput, $err);
echo json_encode($array);Analysis results:
This PHP code has certain security risks:
The $_GET method is used to directly receive the user input parameter rootUname without any filtering or validation. This can lead to security issues such as injection attacks. It is recommended to use input validation and filtering functions, such as filter_input(), to safely process user input.
The code directly uses the rootUname provided by the user to build and execute the command line, which may lead to command injection attacks. An attacker can insert malicious commands in rootUname, causing security issues for the server. In order to prevent command injection, it is recommended to use parameter binding to execute commands, such as using PHP's escapeshellarg() function to escape parameters.
The code executes system commands through the exec() function, which may lead to certain security risks. In actual development, you should try to avoid using such functions that may cause security risks. If you must use it, you should ensure strict validation and filtering of input parameters.
The code directly outputs error information, which may expose sensitive information of the server. In a production environment, it is recommended to handle error messages to avoid outputting detailed error messages directly to users.
In summary, this code is a security risk. In practical applications, it is necessary to fix these problems and pay attention to other aspects of security, such as HTTPS connection, access control, etc.
4》XML external entity injection (XXE) attack vulnerability detection
PHP code 3:
<?php
libxml_disable_entity_loader (false);
$xmlfile = file_get_contents('php://input');
$dom = new DOMDocument();
$dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD);
$info = simplexml_import_dom($dom);
$name = $info->name;
$tel = $info->tel;
$email = $info->email;
$password = $info->password;
echo "Sorry, $email is already registered!";
?>Analysis results:
One security issue with this code is the risk of XML External Entity (XXE) injection attacks. The problem is with the libxml_disable_entity_loader(false) function, which allows resolving external entities. Attackers can read sensitive files on the server or launch network attacks by constructing malicious XML input.
To fix this problem, you can prevent XXE attacks by disabling external entity loading, and change libxml_disable_entity_loader(false) to libxml_disable_entity_loader(true) in the code.
Also, use the LIBXML_NOENT and LIBXML_DTDLOAD options with caution, as they can cause security issues.
In addition, this code does not validate and escape user input, which may lead to other security issues, such as cross-site scripting (XSS). Therefore, be sure to validate and escape effectively when handling user input.
5"XML External Entity Injection (XXE) Attack Vulnerability Detection
This code is relatively long, please see XmlReader_Tests.cs in the code base, GPT-4 can handle long scripts. It has the feature of long token. I will take a screenshot to show you the code length.
Analysis results:
This test code contains three test cases that test the parsing of XML documents using XmlReaderSettings and XmlReader respectively. We analyze one by one:
XMLReader_WithDTDProcessingParseAndXmlResolverSet_NotSafe(): In this test case, the XML parser is not set safely. DtdProcessing.Parse allows parsing of Document Type Definitions (DTD), while XmlResolver is XmlUrlResolver, which means that external entities can be parsed. This can lead to XML External Entity (XXE) injection attacks.
XMLReader_WithDTDProcessingIgnored_Safe(): In this test case, the setting of the XML parser is relatively safe. By setting DtdProcessing to DtdProcessing.Ignore, the parser ignores the DTD, thus avoiding XXE attacks. However, it's worth noting that xmlDocument.XmlResolver is still set to XmlUrlResolver. Although it does not cause a security problem in this test case, in actual use, it is best to set the XmlResolver to null to avoid potential security risks.
XMLReader_WithDTDProcessingProhibited_Safe(): In this test case, the setting of the XML parser is safe. DtdProcessing.Prohibit prohibits the parsing of DTDs, effectively preventing XXE attacks. But similar to the previous test case,
Summary of audit capabilities for GPT-4:
GPT-4 demonstrates the following capabilities during code audits:
Keen security awareness: When auditing code, you can quickly discover possible security risks in the code and point out these problems in a timely manner.
Comprehensive analysis ability: When analyzing code, I can comprehensively consider various possible security issues, from input verification to sensitive information disclosure and other aspects of analysis.
Dynamic debugging and simulated execution: By simulating the code execution process, it is possible to understand the code logic more deeply, thereby discovering potential security risks.
Targeted solutions: After discovering problems, specific solutions can be given to improve code security.
Continuous learning and adaptation: With the continuous development of the network security field, it is possible to continuously learn new knowledge and technologies in order to better deal with the security analysis capabilities of various codes.
During the code audit process, he demonstrated strong security awareness and analysis capabilities, and gained a deeper understanding of code logic through dynamic debugging and simulated execution. However, security auditing is a complex and ongoing process that requires continuous learning and improvement.
The following is the result of the GPT-3 analysis code.
Example 1:
Here's a simple C program vulnerable to format string attacks:
`#include <stdio.h>`
`int main(int argc, char **argv) {`
`printf(argv[1]);`
`return 0;`
`}`Vulnerabilities detected:
1. Unvalidated user input: The program does not check the length of user input, which can lead to buffer overflow attacks.
2. Format string vulnerability: The program does not check the format of user input, which may lead to format string attacks.
Example 2:
Let's try this with a not-so-simple program written in a high-level language, such as this C# program that contains the Log Forging vulnerability. I've personally seen similar (though less trivial) code in open source projects and production codebases:
`using Microsoft.AspNetCore.Http;`
`using Microsoft.AspNetCore.Mvc;`
`using Microsoft.Extensions.Logging;`
`using System;`
`using System.Collections.Generic;`
`using System.Linq;`
`using System.Threading.Tasks;`
`namespace WebFox.Controllers`
``
`[Route("api/[controller]")]`
`[ApiController]`
`public class LogInjection : ControllerBase`
`{`
`private readonly ILogger<LogInjection> _logger;`
`public LogInjection(ILogger<LogInjection> logger)`
`{`
`_logger = logger;`
`}`
`[HttpGet("{userInfo}")]`
`public void injectLog(string userInfo)`
`{`
`_logger.LogError("error!! " + userInfo);`
`}`
`}`
`}`Vulnerabilities detected:
Log Injection Vulnerabilities: The code is vulnerable to log injection attacks because user input is logged without any sanitization.
Example 3:
The following C program reads and manipulates images. It contains a number of security holes, including out-of-bounds reads and writes:
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
struct Image
{
char header[4];
int width;
int height;
char data[10];
};
int ProcessImage(char* filename){
FILE *fp;
char ch;
struct Image img;
fp = fopen(filename,"r");
if(fp == NULL)
{
printf("\nCan't open file or file doesn't exist.");
exit(0);
}
printf("\n\tHeader\twidth\theight\tdata\t\r\n");
while(fread(&img,sizeof(img),1,fp)>0){
printf("\n\t%s\t%d\t%d\t%s\r\n",img.header,img.width,img.height,img.data);
int size1 = img.width + img.height;
char* buff1=(char*)malloc(size1);
memcpy(buff1,img.data,sizeof(img.data));
free(buff1);
if (size1/2==0){
free(buff1);
}
else{
if(size1 == 123456){
buff1[0]='a';
}
}
int size2 = img.width - img.height+100;
//printf("Size1:%d",size1);
char* buff2=(char*)malloc(size2);
memcpy(buff2,img.data,sizeof(img.data));
int size3= img.width/img.height;
//printf("Size2:%d",size3);
char buff3[10];
char* buff4 =(char*)malloc(size3);
memcpy(buff4,img.data,sizeof(img.data));
char OOBR_stack = buff3[size3+100];
char OOBR_heap = buff4[100];
buff3[size3+100]='c';
buff4[100]='c';
if(size3>10){
buff4=0;
}
else{
free(buff4);
}
free(buff2);
}
fclose(fp);
}
int main(int argc,char **argv)
{
ProcessImage(argv[1]);
}Vulnerabilities detected:
1. Unchecked return value: The return value of the fopen() function is not checked, which may result in a null pointer dereference.
2. Out-of-bounds read: The memcpy() function is used to copy data from img.data to buff1 and buff2 without checking the size of the destination buffer, which may lead to out-of-bounds reads.
3. Out-of-bounds write: The writing of the buff3 and buff4 arrays does not check the size of the source buffer, which may lead to out-of-bounds writes.
4. Uninitialized memory access: OOBR* stack and OOBR *
Heap variables are accessed while uninitialized, which may lead to undefined behavior.
5. Memory leak: If the size3 variable is greater than 10, the buff4 array will not be released, which may cause a memory leak.
GPT-3 is correct for 4 of 5 of them. Vulnerability 1 is a false positive because fopen()the value of is checked in the row if(fp == NULL). Also, the wording of Vulnerability 4 is misleading - it is correct to refer to two uninitialized memory access errors in the line of code, but it points to the wrong variable name.
Example 4:
The last Java example is my favorite, because unfortunately, when I first read this code, I didn't see anything wrong with it. To me it looks completely innocuous and familiar - I've seen similar code in the wild but never had any second thoughts.
class Utils
{
// Function to serialize an object and write it to a file
public static void SerializeToFile(Object obj, String filename)
{
try
{
FileOutputStream file = new FileOutputStream(filename);
ObjectOutputStream out = new ObjectOutputStream(file);
// Serialization of the object to file
System.out.println("Serializing " + obj.toString() + " to " + filename);
out.writeObject(obj);
out.close();
file.close();
}
catch(Exception e)
{
System.out.println("Exception: " + e.toString());
}
}
// Function to deserialize an object from a file
public static Object DeserializeFromFile(String filename)
{
Object obj = new Object();
try
{
FileInputStream file = new FileInputStream(filename);
ObjectInputStream in = new ObjectInputStream(file);
// Deserialization of the object to file
System.out.println("Deserializing from " + filename);
obj = in.readObject();
in.close();
file.close();
}
catch(Exception e)
{
System.out.println("Exception: " + e.toString());
}
return obj;
}Vulnerabilities detected:
1. Insecure deserialization: Deserializing untrusted data can lead to remote code execution.
2. Insecure file permissions: A file being written or read may have insecure permissions, allowing unauthorized access.
The Ultimate "Shift Left" in Cybersecurity
Shift left is the process of applying security practices early in the development process -- such as testing for security vulnerabilities before deploying code to production.
By applying best security practices and educating developers on cybersecurity as they write and commit code, AI code analysis could represent the ultimate shift left in cybersecurity. This can really foster a strong cybersecurity culture within the organization and even prevent the next big hack, but…
Admittedly, the technology is not perfect, and it misses a few things that a seasoned cybersecurity professional wouldn't miss when conducting an audit. Still, it's surprisingly good as a general-purpose large language model, and much cheaper than other alternatives.
GPT-4 does not currently have a release date, but I believe these large language models will continue to evolve as they gain more and more features.
An example of a false positive
After manually inspecting about 60 of the 213 vulnerabilities detected by GPT-3, I found that one of the notable false positives was located on line 13 of this Javascript program:
var express = require('express');
var cookieParser = require('cookie-parser');
var escape = require('escape-html');
var serialize = require('node-serialize');
var app = express();
app.use(cookieParser())
app.get('/', function(req, res) {
if (req.cookies.profile) {
var str = new Buffer(req.cookies.profile, 'base64').toString();
var obj = serialize.unserialize(str);
if (obj.username) {
res.send("Hello " + escape(obj.username)); // <--- GPT-3 makes a mistake here
}
} else {
res.cookie('profile', "eyJ1c2VybmFtZSI6ImFqaW4iLCJjb3VudHJ5IjoiaW5kaWEiLCJjaXR5IjoiYmFuZ2Fsb3JlIn0=", {
maxAge: 900000,
httpOnly: true
});
}
res.send("Hello World");
});
app.listen(3000);Vulnerabilities detected:
Insecure cookie setting (secure flag not set)
Unvalidated user input deserialization (cookie)
Potential XSS vulnerability due to unescaped user input (username)
GPT-3 was right about the first two bugs, but the third bug was a false positive — it was obj.usernameescaped, but GPT-3 said it wasn't.
result:
Experimental results show that GPT-3 is able to detect security vulnerabilities in 85 of the 129 scanned files. The ability is no less than a code audit expert!
{name:'.php', value:50}, {name:'.js', value:20}, {name:'.cs', value:16}, {name:'.c', value:14}, {name:'.java', value:9}, {name:'.py', value:8}, {name:'.rb', value:5}, {name:'.asp', value:3}, {name:'.ts', value:2}, {name:'.go', value:1}, {name:'.html', value:1}
{name:'Vulnerabilities found', value:73}, {name:'No vulnerabilities found', value:43}, {name:'Vulnerabilities found', value:6}, {name:'Answer', value: 2}, {name:'Potential vulnerability', value:2}, {name:'Analysis', value:1}, {name:'Security vulnerability', value:1}, {name:'No answer provided', value:1}
For more analysis results of asp, php, java, c, js, cs and other scripts, please refer to the code library in front of the article.
Summarize
This article describes the process and results of auditing code using ChatGPT. The authors used GPT-3 to detect 213 security vulnerabilities, 85 of which were detected correctly. GPT-3 has a relatively low false positive rate, but there are still some vulnerabilities that are either misreported or underreported. The author believes that GPT-3 can be used as an auxiliary tool to help find security vulnerabilities, but it cannot completely replace manual audits.
GTP-4 can handle long codes, which means that there is no need to cut the codes, and there is no need to guide too much. During the code audit process, he demonstrated strong security awareness and analysis capabilities, and gained a deeper understanding of code logic through dynamic debugging and simulated execution. Although much more powerful than GPT-3, there is still a long way to go.