软件工程师的代码安全

我们选取了全球4万家组织的100万名开发者编写的80亿行代码。

And we we took 8,000,000,000 lines of code that was written by 1,000,000 developers of 40,000 organizations globally.

这是一个相当大的数据集，然后我们分析了发现的问题。

So quite a dataset, and then we looked at what are the issues we we see.

我认为一个发现是大约每1000行代码中就存在一个安全问题，这也反映了我手动审计代码时的感受。

And I think one finding was that every about 1,000 line of code, we we see a security issue, and that reflects kind of, well, my my my feeling of when I manually audited code.

所以每1000行代码就出现问题的频率，我认为是相当高的。

So every 1,000 line of code and issues is quite a lot, I think.

我们发现和看到的问题类型正是我们之前讨论过的基本类型。

And then the issue types we found and saw were the basic ones we talked about.

对吧？

Right?

至少在前五名中最常见的。

The most in the top five, at least.

对吧？

Right?

存在日志注入、跨站脚本攻击、SQL注入、硬编码密码等典型问题。

There was log injection, crosshat scripting, SQL injection, hard coded passwords, the typical things that that that go wrong.

我认为其中关于正则表达式的发现有些出人意料，比如我们经常或更常见地会遇到执行缓慢或不安全的正则表达式，这可能导致拒绝服务攻击，这类问题相对更偏离常规。

I think some surprises were in there about regular expressions, for example, was was something that we are typically or more often, apparently, you know, we have a slow regular expression or insecure regular expression, which can lead to denial of service attacks, And so that would be something more out of the lines.

不过，是的，这些基础问题至今在代码中仍然非常突出。

But, yeah, the the basic ones are still very prominent today in code.

这非常有趣，因为你提到大约每1000行代码就会出现一个安全问题。

It's very interesting because you like, you're saying every 1,000 lines of code, roughly one security issue.

这很有趣，因为我们总是争论代码行数的问题。

That's funny because lines of code, we always argue about.

它是否真的能衡量复杂度、工作量等等？还是说不能？

Is it a good measurement of things, you know, complexity, work, whatnot, or or is it not?

但我想，你仍然在使用这种启发式方法。

But I guess, you know, you're you're still using this heuristic.

对吧？

Right?

我是说，这是我们为报告构建的一个统计数据。

I mean, it's it's it's a statistic we built for the report.

对吧？

Right?

但我认为，是的，归根结底，这里的质量确实与安全性息息相关。

But I think, yes, I think what comes down to that is is that quality here is really connected to to security.

对吧？

Right?

我的意思是，你可以用更多或更少的代码行数来解决某些问题，而我认为代码质量在这里非常关键——当代码量越大时，审查的工作量就越大，最终维护安全性也越困难。当然，如果能以良好维护和结构化的方式编写就另当别论。

I mean, you could solve certain problems with, you know, more lines of code or with less lines of code, and I think equality is something here that, you know, is very related in terms of when you have more lines of code, right, there's more, you know, code to review, basically, and it's it's harder to support security issues in the end while if if you do it in a well maintained and and and structured way.

确实如此。

Exactly.

但这正是我对这件事的直观感受。

But this was exactly my feeling on on this.

那么，你会怎么说呢？

So, like, what would you say?

代码质量与安全性之间有何关联？

How was the quality of code related to security?

你们在这方面有什么发现吗？

Did you see any findings on this?

是的。

Yeah.

我认为它们高度相关。

I I think it's super related.

对吧？

Right?

而且我觉得这在当今行业中被严重低估了。

And I think it's it's totally underrated in in the industry today.

我们讨论过空指针异常或这些低效的正则表达式，它们可能导致安全问题，这些算是比较明显的缺陷案例。

We I mean, we talked about the the null pointer exceptions or these slow regular expressions, right, that can lead to security issues, and and that's more maybe the obvious examples of bugs.

但如果你想想那些难以阅读、维护不善的代码，比如所谓的'意大利面条式代码'，一开始可能不太明显它们与安全性的关联。

But, also, if you think about unreadable codes, not well maintained code, right, as kind of like spaghetti code, then it's not so obvious at first maybe how this is connected to security.

但如果你考虑到代码不易理解、不易审查，而你的开发团队又进行结对编程或代码审查时，在这种意大利面条式的代码中，你更有可能忽视同事代码中的安全问题。

But then if you think about that code is not easy to comprehend, not easy to review, and you do pair programming or code reviews in your development team, then in that spaghetti code, you will more likely oversee security problems of your peer.

再想想修复安全问题的情况，比如现在可能有人发现了问题或后来发现问题并反馈给你，而你作为开发者必须修复它。

And then also if you think about fixing security issues, right, like now maybe someone found an issue or found later an issue and reports that back to you, and you as a developer have to fix it.

想象一下如果那是难以维护的代码，你就无法修复那个安全问题。

Think about if that's, you know, not well maintainable code, you you you cannot fix the problem, the security problem.

因此代码质量突然就变成了安全问题，因为攻击者的机会窗口会开放得更久。

So quality suddenly becomes a security issue in the sense that the, you know, attacker window stays open longer.

到某个时候，你不得不修复这些问题。

At some point, you have to to fix the issues.

所以我认为你的代码质量与代码安全高度相关，特别是在AI生成代码普遍质量较差的当下。

And so I think your code quality is super related to code security, especially now with AI generated code where we see typically poor quality of code.

对吧？

Right?

这就成了安全问题。

And that becomes a problem for security.

当我们讨论代码安全时，它与整体网络安全有何关联？

When we look at code security, how does that relate to cybersecurity as as a whole?

所以

So there

安全领域包含许多方面。

are many fields of security.

对吧？

Right?

有数据安全、云安全、网络安全、取证安全等。

There's data security, cloud security, network security, forensics.

作为一个大型组织，你基本上需要所有这些方面，它们相互关联，共同构建多道防线。

As a larger organization, you kind of need all of them, and they are all interconnected, and they build multiple lines of defenses.

从我的角度来看，从进攻性安全的角度来说，我发现应用安全始终是最有趣的领域，因为想想看，如今每个组织基本上都在部署软件。

From my perspective, from an, you know, offensive security perspective, I found application security always the most interesting field because if you think about, you know, every organization today basically deploys software.

他们要么将软件作为产品交付，要么在线部署某些服务让客户与其业务互动。

They they they ship software as a product, or they deploy some services online to have customers interact with their business.

因此这些应用程序是7×24小时在线的。

And so those applications are online twenty four seven.

对吧？

Right?

而且它们对我这样的攻击者来说是可利用的。

And they're available to to me as an attacker.

这就是安全的最前线，通常也是进入网络的第一道入口。

And that's the, you know, at the forefront of security and and typically the first entry point into the network.

这使得应用安全领域对攻击者来说既至关重要又充满吸引力。

And so that makes it so so critical, also interesting for attackers, the the application security field.

而其他安全领域更多是试图阻止横向移动。

Whereas the other areas, you know, more try to prevent the lateral movement.

一旦攻击者入侵，能否让他无法解密窃取的数据？或者无法从一台服务器转移到另一台？

Once an attacker is in, can the attacker maybe not decrypt the data he stole, or can the attacker not, you know, move from one server to the other?

什么是横向移动？

What is lateral movement?

是的。

Yeah.

通常来说，作为攻击者，你会先获得进入网络的第一个切入点，然后可能想从那里进一步扩展。

So, typically, as an attacker, you would, you know, gain your first entry point into a network, and then maybe you wanna expand from there.

比如你在某台服务器上获得了一个shell。

So you have a shell on one server.

你可以控制一台服务器或机器。

You can control a server or a machine.

你可以运行系统命令，然后从内部网络尝试探查：还能访问哪些其他服务？哪些内部资源？

You can run system commands, and then you would from there, you know, you are in the internal network and try to see what other services can I reach, what other internal things can I access?

因此需要制定安全策略——更广泛地说，是网络安全策略——来防止这种内部服务间的横向移动。

And then you need a security strategy, basically, in the broader cybersecurity strategy to prevent that lateral movement between internal services.

关于横向移动，我想到一个观点。

One idea that comes to me about lateral movement.

随着AI助手和MCP服务器的出现，这很可能会成为极具诱惑力的攻击途径——攻击者会想：让我试试获取那个开发人员的机器权限。

With the advent of AI assistants, MCP servers, it's probably gonna be a pretty tempting attack vector for just thinking as an attacker, hey, let me try to get access to that developer's machine.

我会搭建一个声称具有某种功能的MCP服务器，但实际上它暗中执行其他操作，在本地运行，砰的一声。

You know, I'll set up an MCP server that says it does something, but secretly it does something else, it runs locally, Boom.

我就获得了这位开发者的机器访问权限。

I get access to this developer's machine.

作为开发者和安全专业人员，我们该对此有多担忧？

As developers and as as security professionals, how much should we worry about this?

你们是否观察到针对这一特定攻击因素的担忧？

And are are you seeing any worries about this specific attack factor?

因为我感觉迄今为止，开发者的机器某种程度上算是禁区，或者说它们真的是禁区吗？

Because I feel until now, developer's machines were kind of a little bit off limit, or were they off limits?

是的。

Yeah.

我认为开发者的机器并非禁区。

I mean, developers' machines, I think, are not off limits.

对吧？

Right?

我认为供应链攻击是一个重大议题，开发者构建的软件会被部署到全球各个组织中，这使其变得尤为关键。

I think supply chain attacks is a a big a big topic where, I mean, developers are building software, and then software is deployed on all the organizations worldwide, right, and that makes it so interesting.

我们讨论过通过入侵开发者机器来破坏NPM包的案例，进而可以入侵极其流行的依赖项。如果你是软件供应商，必须确保交付给数千家组织的软件不会因某个开发者被入侵而被植入后门。随着智能代理的普及，新威胁也随之而来——不仅要关注依赖项安全或机器安全，还要确保使用的代理行为正当，不会因权限过高而有意或无意造成危害。比如代理处理Jira工单时，恶意工单可能诱导其植入后门而非解决开发问题，这就衍生出全新的安全隐患。

So we talked about an NPM package that gets compromised by compromising a developer's machine basically, right, and then from there, you can compromise a super popular dependency, right, or if you're a software vendor, you better make sure the software that is shipped to thousands of organizations maybe is not backtowered because some developer got backtowered, and yes, I think also with agents and and giving way more control, there is a a new threat here because it's not just about the dependencies you're using or your machine security in general, but also making sure that the the agent you're using is doing the right thing and doesn't have the privileges to do something accidentally or on purpose, as you said, to do something harmful, like if the if the agent passes a Jira ticket and something is you know, someone can create a malicious Jira ticket that instructs, basically, the agent to add a backdoor and just in instead of just solving a development problem, then you suddenly have a new, you know, type of security problem to think about.

你之前提到过，在代码安全或应用安全方面，能自动化的工作都应尽量自动化。

You previously mentioned that if you can automate things as for for code security or application security, you should try to do that.

你常见到工程团队使用哪些代码安全工具来维持安全卫生？

What are the common code security tools that you've used you keep seeing engineering teams use for security hygiene?

比如，我能想到哪些类别？

Like, what are the categories that that I can think of?

我认为每个开发者都会使用IDE。

I think every developer uses an IDE.

对吧？

Right?

所以IDE中提供了一些基本的代码检查功能，这很棒。

So there is some basic linting available in IDEs, and that's great.

对吧？

Right?

就像你在输入时发现问题，然后可以解决它们。

Like, because as you type, you find issues, and you can resolve them.

只是在集成开发环境中，通常没有这么广泛或深入的安全检查功能内置。

Just that in an IDE, typically, you don't have such a broad or in-depth security coverage built in.

对吧？

Right?

你可以使用一些IDE扩展插件，但通常仍停留在代码检查层面。

There are some IDE extensions you can use, but then, typically, you stay at the linting side.

这意味着进行一些语法和语义检查，而且通常只针对当前工作文件，纯粹出于性能考虑。

That means some syntactical and semantical checks, and typically in the current file you're working in, simply out of performance reasons.

对吧？

Right?

因为这些检查必须在编码时毫秒级完成，不能拖慢你的工作速度。

Because it has to be done in milliseconds as you code and shouldn't slow you down.

然后你还有静态应用程序安全测试工具，SaaS工具，可以进行更深入的代码分析。

And then you have static application security testing tools, SaaS tools, that can go more into a deeper level of of code analysis.

对吧？

Right?

所以根据你使用的SaaS工具不同，可能会采用符号执行或污点分析等技术，将整个代码库转换为抽象模型，然后通过静态分析模拟运行时可能发生的情况——它并不实际执行代码，而是通过分析我们之前讨论过的用户输入等问题，追踪数据流在所有代码路径中的走向，模拟可能出错的地方来发现各种问题。

So and depending on the SaaS tool you use, there is, for example, symbolic execution or taint analysis techniques used where your whole code base is transformed into an abstract model, basically, and then it's simulating static analysis is simulating what could happen here at runtime, what it's not executing the code, right, but but analyzing this and connecting what we talked earlier about user inputs, for example, how are they flowing in terms of data flows through through all your code paths and simulating what what could go wrong here to find different issues.

能不能简单给我们概括一下整个过程？

And and can you just give us a high level of of of what is happening?

因为这听起来非常有趣。

Because this sounds super interesting.

我的理解是——如果我理解有误请指正——你把代码转换成某种图形结构，然后可以尝试分析输入如何流动、如何到达各个组件。

What I understood and, you know, tell me if I if I got it right is you you take your code and you kinda turn it into, like, maybe a graph or or of some sort, and then you can try to figure out kind of inputs, how they can flow, how they can get to components.

是的。

Yeah.

完全正确。

Exactly.

所以你的代码会被转换成一个大型的图模型。

So your your code is is transformed into a big graph model.

这个图可以是任意维度的。

This can be any dimensions.

是的。

Yes.

没错。

Right.

基本上，代码库中的每个文件、每个函数、每个if-else语句都会被纳入其中。

So so every basically, every file of your code base, every function, function, every if else, basically.

每当应用程序的控制流发生变化时，每个函数调用、每个if-else分支都会成为这个大图模型的一部分。

So whenever the control flow of your application changes, every function call, every if else is a part of that big graph model.

对吧？

Right?

然后你要找出所有可能的组合——那些创建数据流的变量赋值，用户输入在应用程序中的接收点，以及它们如何通过不同的if-else分支和函数调用进行传递，最终到达哪些安全敏感的位置。

And then you try to figure out what are all the combinations where, you know, your variable assignments, which which create data flow, basically, where is user input received in that application and then passed on with, you know, data assignments through different if else and function calls, and where does it end up in something security sensitive.

对吧？

Right?

而且这些数据流路径可能非常非常长，要正确处理并高效执行也非常复杂。

And this can be very, very long data flow paths and very complicated to do right and also to do that efficiently.

对吧？

Right?

过去这需要花费数天时间，而现在我们能在几分钟内完成，这是个非常难解决的问题。

It it used to be taking days, and and now we can do that in minutes, and that's a very hard problem to solve.

但它能帮助你自动化那个流程，对吧？就是我们之前讨论的要留意用户输入的部分。

But it helps you to automate that that that process, right, what we talked about earlier where you should be be mindful of what is user input.

它能帮你自动化这个过程，并找出用户输入与敏感安全点之间那些非常棘手且冗长的关联。

It it helps you to automate that and find even very tricky and long connections between user input and something security sensitive.

好的。

Okay.

所以我们讨论了集成在IDE中的那些linter工具，就是你提到的SAST扫描器。

So we talked about the kind of linters inside IDs, the SAST, s s a s t scanners that you said.

还有哪些值得了解的工具吗？

Are there other tools worth knowing about?

比如密钥检测，我们讨论过硬编码密码之类的，所以有专门的密钥检测工具。

I mean, secret detection, we talked about hard coded passwords or so there are secret detection tools.

还有基础设施即代码扫描。

There is infrastructure as code scanning.

对吧？

Right?

如果你从更广义的角度看代码，基础设施即代码也算，或者你的GitHub Actions文件也可以视为代码。

If you think about code more broadly, it's also infrastructure as code, or your GitHub actions file can be code.

对吧？

Right?

而且有专门的工具可以扫描这些内容。

And there are there are tools to scan this.

通常来说，如果你有一个好的SaaS工具，这些基本上都被静态分析覆盖了，对吧？因为在这里所有东西都可以被视为代码。

Typically, if you have a good SaaS tool, that's all covered by by static analysis, basically, right, because everything can be considered code here.

我们之前已经讨论过软件成分分析，这是开发者的另一个工具，用于发现依赖项中已知的漏洞，即那些CVE。

And then we talked already about software composition analysis as another tool for developers where you find those known vulnerabilities, those CVEs in your dependencies.

我想这是一种分层方法。

I guess this is a layered approach.

对吧？

Right?

所以你想要的安全级别越高，就需要设置更多这样的防护层。

So the the more security you'd like, the more of these layers you would set up.

但我是不是感觉到这些方法之间存在权衡？

But do I do I sense that there's a trade off between them?

可能会增加复杂性、运行时间这类问题。

It's going to be maybe complexity, time to run, those kind of things.

比如说，如果我把所有这些工具都堆到每个代码库上，即使我只是个单人创业公司，会有什么弊端？

Like, what what is the downside of just, like, throwing all of these tools onto every single code base I have even if I'm a if if I'm a one person start up.

对吧？

Right?

比如，如果你不建议这么做，那为什么不推荐呢？

Like, why would you not recommend that if if you would not recommend it?

是的。

Yeah.

我认为，对于基本的静态分析工具，我绝对推荐使用。

I think I mean, for the the basic static analysis tools, I would definitely recommend to do that.

我觉得这里需要注意选择那些专为开发者而非安全团队设计的工具。

I think here, what you should be careful of is choosing something that is, you know, intended to be used by developers and not by security teams.

对吧？

Right?

我们讨论过噪音水平的问题——从安全团队的老视角看可能很有趣，但对产品开发或生产力来说可能是致命的，你不应该被这些干扰，这是需要警惕的。

We talked about the noise level that is, you know, interesting for security teams from an old perspective, but deadly for your product development or, you know, productivity where you shouldn't be annoyed, and and and I think that's something to watch out for.

不过SaaS工具和SCA工具之间也有区别，取决于它们更多面向安全团队还是开发者。但我绝对建议各个层面都运行静态分析和软件成分分析，这是基础的安全卫生措施。

But and and then there are differences, you know, for SaaS tools and SCA tools if they are more for the security teams or for developers, but I would definitely recommend, I think, all levels to to run static analysis and software composition analysis to have your your basic security hygiene in place.

这些都是静态工具。

So these are static tools.

它们可以在你运行代码后对这些代码进行分析。

They after you run the code, they can run on them.

它们可以在持续集成(CI)环境中运行。

They can run on CI.

它们可以与持续部署一起运行。

They can run with continuous deployment.

有没有更偏向动态分析的工具？

Are there kinda more dynamic tools?

我在想的是那种随着代码运行、服务器运作时，能动态进行测试或尝试各种非常规操作的工具。

And I'm just kind of thinking of of of the idea that, you know, as your code runs, as your servers operate, that dynamically try to test or or or just do funky stuff.

当然有。

Absolutely.

这就是动态应用安全测试(DAST)。

So there's dynamic application security testing.

我们之前讨论过渗透测试。

We we talked about penetration tests.

对吧？

Right?

而Dust工具正是试图将这个过程自动化。

And and and the Dust tool tries exactly to automate this.

对吧？

Right?

Dust是什么？

What is Dust?

动态应用程序安全测试是从外部以黑盒方式进行的测试，当你的应用程序已在测试服务器或生产环境中运行时，它会从外部向你的应用程序发射各种恶意负载，观察其反应——是否会崩溃、出现延迟等问题。

Dynamic application security testing is testing from the outside as a black box when your application is already running on a test server or in production, and it's basically shooting all kinds of malicious payloads from the outside against your application to see how it reacts, and is it breaking or, you know, is there a delay?

它的行为是否异常或抛出错误信息？

Is it behaving weird or throwing an error message?

通过这种方式，试图将这种人工渗透测试自动化，以发现是否存在可检测到的问题。

And in this way, trying to automate such a human penetration test to find out if there are issues it can detect.

动态测试方面还有模糊测试，这与Dust类似，主要针对嵌入式软件，如二进制文件、C/C++库或应用程序，通常处理复杂格式或协议（如文件格式），然后你基本上会翻转处理过程中的每一个比特位，看看是否会导致程序崩溃。

And then there's also on the dynamic side fuzzing, which is similar to Dust, basically, where it's more for embedded software, you know, binaries, c c plus plus libraries or applications where typically you pass complex formats or protocols like file formats, and then you wanna flip every single bit basically in what you're processing to see if something breaks.

对吧？

Right?

你可以通过模糊测试自动化这个过程，然后发现那些崩溃。

And you can automate that with fuzzing and then find those crashes.

所以这种方法效果很好。

So that that works very well.

我只是认为，那些更动态的工具对现在的开发者来说不太适用，因为你与编码过程有点脱节，需要切换上下文，无法在编写代码时即时发现问题。

I just think that, you know, those more dynamic tools are not so much for developers today because you are a bit disconnected from your coding and, you know, you you have to context switch basically because you cannot find things as you type.

你需要先完成手头的工作，部署到测试服务器上运行，然后反馈周期就会变得稍长一些。

You need to kind of, like, finish what you're doing, deploy it on the test server, get it run, and then the feedback loop is just a bit longer.

因此我认为对开发者来说效率较低，但对安全团队来说，拥有一个能额外运行Dust或模糊测试的工具是非常棒的。

And so I think for for developers, it's it's more inefficient, but for security teams, it's it's a it's a great tool to have to to additionally maybe run a Dust or a fuzzing.

对吧？

Right?

是的。

Yeah.

而且

And as

就像你说的，听起来要做一堆准备工作就为了多做一件事。

you say, like, it's it sounds like a bunch of setup to do just one more thing.

我能理解为什么你说这更适合安全团队？

Like, I can I can see why you're saying that it's it's more for a security team?

有件事你没提到，但我一直在等你提，就是AI安全审查。

One thing you haven't mentioned, but I I was waiting if you would mention, AI security reviews.

你知道的，这些现在遍地开花。

These are, you know, popping up everywhere.

有很多不同的工具，不同的供应商，有些是现有的，他们都在说同样的话。

There's there's a lot of different tools, a lot of different vendors, some some existing ones, and they're all saying the same thing.

用这个工具。

Use this thing.

它会让你的代码更安全。

It will make your code more secure.

作为一名软件专业人士，你的看法是什么？

What is your take as a software professional?

我觉得这非常有趣且令人兴奋。

I think it's super fascinating and fun to to see.

对吧？

Right?

而且AI如今能发现的问题也令人印象深刻。

And and also impressive what AI can find today.

就像静态分析或其他技术一样，对我来说，它不仅仅在于发现问题，至少当你想要系统性地作为开发者使用时是这样。

You know, as with static analysis or every other technology, to me, it's not necessarily all about just finding issues, at least when you wanna, you know, use that in a systematic way as a developer.

这里需要找到一个良好的平衡点：不仅要发现问题，还要考虑我报告的这些问题中有多少实际上并非真实或有意义的，以及我能否将其扩展到五十万行代码等等？

Here you have to get into a good balance of am I not only finding things, but how often do am I reporting things that are actually not a true or a meaningful issue, and and can I scale this to half a million lines of code, etcetera?

对吧？

Right?

所以我认为我们现在看到更多的是安全研究代理，它们会随机发现各种问题。

So I think what we are seeing more today is, you know, security research agents that go in and and randomly find issues.

要知道，这对安全团队来说是个非常棒的工具。

You know, it's it's a great tool for security teams here.

但作为开发者，我认为你需要的是更系统化的方案，能发现所有代码安全问题。

But as a developer, you wanna have, I think, something a bit more systematic that that finds all code security problems.

你刚才提到，在我看来还存在确定性与非确定性的区别。

And you mentioned maybe the the you know, to me, there's another aspect of being deterministic versus nondeterministic.

对吧？

Right?

这里的AI本质上是非确定性的，我认为这对安全领域不太重要，但作为开发组织，你需要建立质量关卡，确保团队间的一致性，保持稳定输出，不能因为随机出现或消失的问题导致关卡失效。

Here, the the AI basically is nondeterministic, and I think, you know, again, for security, that's not so important, but as a development organization, you you need to have basically, like, a a quality gate, and that's consistent across your team and all the other teams that always has the same output, and you cannot fail your gates, you know, because randomly a new issue is popping up or disappearing, etcetera.

所以我认为这对当今的开发者并不太适用。

So I think that that doesn't really work well for developers today.

最后从开发者角度看，这里还存在矛盾——根据调查对象不同，很多代码本就是AI生成的。

And lastly, to me, from a developer perspective, right, there's also a a bit of a contradiction if you think about most or or a lot of code is written by AI itself, right, depending on who you ask.

若再用AI来审查AI生成的代码，就像让学生自己批改作业——如果AI本就能避免生成安全问题，为何事后又能检测出这些问题呢？

And if you then use AI to review AI generated code, that's a bit, you know, having students grade their own homework where you you you would think that, you know, if AI didn't you know, could prevent actually generating a security issue, why would it later on detect that security issue?

所以我认为我们需要建立良好的防护措施和验证机制，而不是用AI来验证这些由AI生成的代码。

So I think we need to have good guardrails and verification in place that is not AI to verify then basically basically, this AI generated code.

我...我能理解你的出发点。

I I I can see where you're coming from.

不过我也能想到有些人可能会说，如果是不同的AI呢？

Although, I can also see some some people might say, like, well, what if it's a different AI?

如果是不同的大语言模型呢？

What is a different LLM?

你知道，就是有差异的那种。

You know, like, difference.

懂吗？

Know?

但我们...我们还是在互相追逐。

But I I we're we're still not, you know, we're just chasing one another.

我们还是没有解决核心问题。

Like, we're still not chasing the core problem here.

你之前提到AI可能生成低质量代码，当我们讨论每行代码对应的安全问题时，这可能会成为一个隐患。

And earlier you said that AI can generate low quality code, and this could be an issue when we're talking about the the lines of code per per security issue.

你能稍微

Can you go a little

详细说明一下你观察到的现象吗？

bit into more detail on in what you're seeing, observing?

在这个语境下，低质量具体指什么？是指我们有时看到的冗长特性吗？

What what what does low quality mean in in this sense, or is it the verbose nature of that we're sometimes seeing?

比如在Sonar，我们对主流大语言模型进行了深入研究，包括Claude Sonar、GPT-4、5、Lama、OpenCoder等。

So, for example, at Sonar, we did great studies of the most popular LLMs, like Claude Sonar, GPT four, five, Lama, OpenCoder, etcetera.

我们分析了它们所谓的'个性特征'。

And we looked at the what we call personalities of them.

对吧？

Right?

我们研究了它们会产生哪些类型的问题、产出代码的质量如何，并对输出结果进行了量化分析和研究。

How do they what kind of issues do they produce, and what kind of quality are they producing, and then measured what comes out of of of that and studied this.

其中一个有趣的发现是，比如当你使用GPT-5的推理模式时，实际上会减少——虽然不是完全消除——但会减少发现的安全问题数量，但它会通过更冗长的输出来解决开发问题。

And one interesting finding to me was, for example, that, you know, if you if you use the reasoning mode of g p d five, it it actually decreases, not eliminates, but decreases the number of security issues you find, but it it's it's using more verbose, you know, output to solve the the development problem.

它实际上会生成更多的代码。

It produces more code, actually.

对吧？

Right?

而这又会导致安全问题的出现，因为你会有更多低质量的代码，这些代码本身可能安全风险较少，但当与其他代码片段结合时就会产生问题，或者同行评审和后期维护会更困难，最终导致安全问题。

And this is then, again, something that leads into security problems because you have more low quality code that maybe have less security issues itself, but then poses a problem maybe combined with other snippets of your code, or it's it's harder to review by your peers or later on, and it's less maintainable and and, you you know, leads to a security problem.

这让我想起在AI时代之前有句老话：代码就是负债。

This reminds me of there's this, like, old saying before AI, that code is a liability.

你拥有的代码越多，你的负债就越多。

The more code you have, the more liability you have.

这就是为什么在过去，有经验的工程师有时会花一两天时间减少代码行数，重构、压缩代码，实现单一职责，消除重复。

And this was a reason that, you know, back in the day, as an experienced engineer would sometimes spend a day or two reducing the lines of code, refactoring, compressing it, bringing single responsibility, moving duplication.

我在想我们是否有点忘记了这个道理：代码行数越多——就拿你说的每千行代码一个安全问题的统计数据来说（暂且接受这个数据）——问题就越多。

And I wonder if we're kind of forgotten this a little bit, that the more lines of code you have, I mean, just taking your statistic of one security issue per thousand lines of code, let's just take it for now.

嗯，是的。

Like, yeah.

就像，你知道的，你会希望代码行数尽可能高效。

Like, you know, like, you you would want to have kind of an efficient lines of code.

对吧？

Right?

就像，你确实应该花时间和精力去构建一个简单、职责明确且简洁的系统。

Like, you do wanna spend that time and effort of of getting to a system that is simple, clear responsibilities, and concise.

我认为这是开发者和工程师现在就需要关注的问题，不仅仅是盲目接受所有生成的代码，而是要确保代码逻辑合理、结构良好，以保持代码库的良好架构，并拥有可维护性强的代码等等——这甚至在安全领域之外就已经是个重大代码质量问题，我想开发者们都意识到了这点。

I think this is something for the developers or, you know, and and engineers look at today already, not just to to wipe code and accept all the code, but to actually make sure that the code makes sense and is is well structured for all kinds of purposes, right, to maintain a good architecture in your in your code base, right, and and to have a good maintainable code, etcetera, outside of the security world, that that's already a a big code quality problem, and and and I think developers are aware of this.

但确实，这也会进一步加剧安全问题。

But then, yes, it it it adds for that to, you know, security problem.

除此之外，我记得Stack Overflow做过一个不错的调查，结果显示只有3%的受访开发者表示信任AI生成的代码，我觉得这个比例非常合理。

On top of that, there was a nice survey by, I think it was Stack Overflow, where I think only 3% of the developers asked, basically, said they they they trust their AI generated code, and I I think that's that's very reasonable.

没错。

Yep.

是啊。

Yeah.

我是说，当我用AI来构建自己的API和测试这些东西时，也经常发现这种情况——我给它指令，时不时还会要求重构某些部分，在查看输出时调整代码结构。

I mean, when when I'm using AI to, like, build myself my APIs and test in all those things, I also find myself like, I I give it instructions, and every now and then, I also tell it to refactor some things, to move things around as I'm watching the output.

我就是看到有些部分变得臃肿了。

I I just see something is getting bloated.

比如有个index.ts文件变得这么大。

You know, I have an index dot t s that is getting this big.

我就觉得，好吧，

I'm like, alright.

先暂停一下，

Let's pause.

我们来重构吧。

Let's refactor.

我这么做是因为，毕竟多年开发经验告诉我，不整理的话代码很快就会变得一团糟。

But I do this because, again, you know, like years of building software, I know that it's just gonna get a mess.

我会完全迷失方向。

I'm not gonna be able to navigate.

对我来说，理解自己的代码并保持清晰的结构至关重要。

And for me, it's important that I need to understand my code and I need to have the structure for that.

所以我认为这一点不会改变，或许那些随性编程的人最终也会学到我们曾艰难领悟的相同教训。

So, I guess this doesn't change or and and maybe the people who are vibe coding, they're gonna come around to learning the same lessons that, you know, we we all learned the hard way.

是的。

Yes.

我想是的。

I guess so.

但如何

But how do

你认为AI是如何改变代码安全以及整体安全性的？

you think AI is changing code security and also security in general?

你看到它已经产生了什么影响？

What impact did you see it's already having?

我是说，变化肯定是有的。

I mean, there's definitely a change.

对吧？

Right?

我认为，即使对我们的安全工具来说，变化也很大，因为它非常强大且有用。

I think I mean, even for our security tools, I think there's a big change in the sense that it's it's it's very powerful and helpful.

所以即便你运行确定性算法（如静态分析）来检测问题，仍然可以用AI来增强这些确定性算法。

So even if if you run deterministic algorithms like static analysis to detect issues, you can still enhance that deterministic algorithms with AI.

对吧？

Right?

比如我们之前讨论过的污点分析。

So, for example, we talked about the taint analysis.

你的确定性分析器需要掌握大量关于现有库和框架的知识，而这些库和框架有数百万之多。

Your deterministic analyzer needs to have a lot of knowledge about all the libraries and frameworks that are there, and there are millions.

对吧？

Right?

因此，人工智能可以帮助你收集知识和信息，然后将其输入到确定性算法中。

And so AI can help you with gathering knowledge and information and then feed that into a deterministic algorithm.

对吧？

Right?

所以你可以结合多种技术，我认为这无疑正在改变静态分析领域，同时也影响着动态分析和其他安全工具领域。

So you can combine technologies, and that's definitely changing, I think, the static analysis, but also dynamic analysis and other security tool areas.

我们还观察到，修复方案的效果相当不错。

And then what we are also seeing is, you know, fixes work quite well.

比如，如果你把50万行代码一股脑儿塞进上下文窗口，效果就不太理想。

Like if you throw half a million line of code, you know, into the the the context window, it's it's not working so well.

但如果你只针对一个非常具体的任务。

But if you just throw in you have a very specific task.

比如你说，这里有一个确定性发现的安全问题。

If you say, here's a deterministically found security issue.

这里有20行代码，这就是问题所在，然后人工智能非常擅长修复这类问题。

Here are the 20 lines of code, and that's the problem, and then AI is very good in in fixing those issues.

对吧？

Right?

所以这非常有用，因为它关乎修复而不仅仅是检测，AI在这方面非常强大。

So so that's very helpful because it's about fixing and not just detecting, and AI is super powerful here.

我们还看到代码和应用程序构建方式的变化。

We we also see, like, a change in how code and applications are built.

对吧？

Right?

传统应用架构中，有后端、前端，后端是数据库。

So if you think about applications traditionally, you have this back end, front end, and in the back end is a is a database.

如果移除数据库，就不会再有SQL注入攻击了。

If you remove that database, then you don't have a SQL injection anymore.

对吧？

Right?

但如果在后端加入LLM，就可能出现提示注入漏洞——攻击者可能篡改系统提示词或你的提示工程，从而干扰LLM的逻辑或输出，这正在改变威胁格局，攻击者会随之调整，当然工具和行业也需要适应，这个过程可能需要些时间。

But if you add an LLM to the back end, then you have a prompt injection, maybe, you know, another vulnerability where the attacker, you know, can modify the system prompt or your prompt engineering and then mess with the LLM's logic or or the the output, and that's becoming then, you know, sort of threat landscape changes, and attackers adjust for it, and and certainly the tools and the the industry adjust to this, and that's that's maybe taking a bit of time.

对吧？

Right?

想想我们现在还能看到的所有COBOL代码。

If you think about all the COBOL code we are still seeing.

是啊。

Yeah.

但我觉得我们可以把提示注入和Ezequiel注入相提并论。

But I I guess we can add prompt injection right up we can pin it up there with Ezequiel injection.

事实上，谁知道呢？

In fact, who knows?

提示注入可能会演变成更严重的安全威胁。

Prompt injection might become even more of a threat security issue.

没错。

Yeah.

我认为随着文本逐渐代码化，提示注入就像是新型的代码注入。

I think as, you know, text becomes code, right, I think prompt injection is kind of like the new code injection.

对吧？

Right?

人类语言就是新代码，如果你注入人类语言，那突然之间这就成了新的代码注入方式。

The human language is the new code, and if you inject human language, then suddenly that's that's your new code injection.

所以从安全角度来看这很有趣。

So that's interesting from a security perspective.

那编程辅助工具呢？

And what about with coding assistance?

你有没有发现我们对代码安全的思考方式正在发生变化？

Are are you seeing things change with in terms of how we think about code security?

我认为安全方面的最大问题是，现在代码生成速度快得多，编写代码已不再是挑战。

I mean, I think the the the big problem in terms of security is that you, you know, produce just code much more faster, and and and writing code is not the challenge anymore.

所以突然之间，新的瓶颈变成了如何验证所有这些代码。

And so suddenly, the new bottleneck is how are you verifying all that code.

对吧？

Right?

现在的新瓶颈不是完成代码，而是验证代码是否真正安全。

That's a new bottleneck, not to get your code done, but to verify it that's actually secure.

如果不这样做，就会导致安全问题或质量问题，长期来看最终会引发安全隐患。

And if if you don't, then that leads to security issues or quality issues, which then, on the long run, lead to security problems.

对吧？

Right?

所以我认为这是安全和代码安全领域面临的新挑战。

So I think that's the big new challenge for for security or code security.

如何大规模、快速地验证所有这些快速生成的代码？

How do you verify all of that faster produced code at scale and at speed?

那么你对目前有效的方法有什么看法？

And what is your take on what is working so far?

我听到很多工程师和工程领导者都在说，显然我们需要扩大代码审查规模。

I mean, the obvious thing that I'm hearing a lot of engineers and engineering leaders say is, like, well, we need to scale code reviews.

我们需要找到方法让人类能审查更多代码，比如增加工具支持，提供更多上下文信息。

We need to figure out ways where humans can look at code reviews, you know, like, more of them, meaning let's add tools to them, let's add additional context.

除此之外，你是否看到其他可能有前景的领域，可以从纯粹的安全角度来验证代码是否安全？

But outside of that, do do you see some other maybe promising areas where where we could actually verify from strictly from a security perspective, like, is this code secure?

是的。

Yeah.

我认为你已经提到了关键点，就是增加工具，在代码生成时自动验证。

I think you mentioned already the the key things, right, to to to add tooling, to to automatically verify a code as you produce it.

我认为还有一些领域，比如SolarSource正在开创性地研究如何通过观察LLM的训练方式，确保其训练数据集没有常见的安全问题。

I think there are also areas where and and SolarSource is pioneering something here in the field where you basically look at how are LLMs trained, and you make sure the data set that an LLM is trained on is actually free of common security issues.

对吧？

Right?

如果你这样做，用高质量、无安全或质量问题的代码和数据训练LLM，从一开始就能生成更安全的代码，这可能是未来我们会看到更多发展的方向。

And if you do that and train your LLM on high quality code, on high quality data, free of security or quality problems, you you are producing from the beginning, right, a much more secure code, and that's maybe another thing where in the future we will see more of this.

说到这个，因为你接触大量代码，做很多安全分析，你是否发现AI生成的代码会引入与人类不同的安全问题类型？毕竟我们知道LLM最终是用人类代码训练的。

And speaking of this, like, again, because you you you see a lot of code, you do a lot of security analysis, do you see AI generated code introduce different types of security issues than humans would do, especially because we know that LMs are trained on, you know, human code in the end.

我认为它们会犯同样的错误，原因正如你所说。

I think they are doing the same mistakes for for the reason you mentioned.

也许某些问题类型的普遍性会发生变化。

Maybe the the prevalence changes of certain issue types.

对吧？

Right?

问题类型本身变化不大，但我们看到例如域名抢注就是个很好的例子，AI会建议使用一个根本不存在的库。

The issue types don't don't change so much, but what we are seeing, for example, slop squatting is a good example where, you know, AI proposes to use a library that doesn't even exist.

对吧？

Right?

然后攻击者就可以在NPM或Maven Central上注册那个不存在的包，突然你就包含了恶意软件，后门就产生了。

And then so an attacker can register in in NPM or Maven Central that that that package, a non existing package, and then with that, you suddenly include a malicious package, and there's a backdoor.

这种安全问题之前就为人所知，我们有过依赖混淆的情况，但开发者不太可能打错依赖项，而有了AI后，这种普遍性突然就改变了。

And so this security issue was known before, and we had dependency confusion, but it's just less likely that that a developer, you know, mistypes a dependency, while with AI, that's that prevalence changes suddenly.

对吧？

Right?

这种情况正在加速发生。

There is an acceleration of that.

而其他类型的问题可能会减少。

While other issues maybe decrease.

对吧？

Right?

我可以想象——虽然目前还没观察到——比如硬编码密码这类单行代码问题可能会减少，因为AI能学会不该这么做，这样我们可能会看到这类问题的减少。

I could imagine, I'm not seeing this for now, but I could imagine hard coded passwords, like some some issues that are just one liner issues maybe decrease a little because AI is able to learn that, you know, I shouldn't do that, and then we could see a reduction of of of, you know, those issues.

虽然人类开发者仍可能添加这些问题，但随着AI生成代码使用增多，这类问题可能会变少。

Still human developers can add them, but maybe the more AI generated code is used, we see less of them.

然后我们可能会看到更多复杂问题。

And then maybe we will see more of the complicated issues.

对吧？

Right?

那些需要组合多个代码片段才能形成的安全问题，AI就不那么容易理解了。

Issues where you need to combine multiple code snippets with each other to form a security issue that is then not so easy for AI to to to to grasp.

所以可以肯定的是，我们已经知道的问题类型分布会发生一些变化。

And so definitely, you know, some changes in the prevalences of of what we know of already today.

关于安全行业，有哪些常见的误解？

What are some commonly misunderstood things about the security industry?

那些我们可以称之为谬误的东西。

Things that, you know, we we we could call them fallacies.

我来自安全行业。

I mean, I come from the security industry.

对吧？

Right?

应该说这些年来我逐渐转向了开发者的角色。

And I I moved more to the developer side of the over the years, I would say.

现在稍微退一步观察安全行业，会发现很有趣的现象：我们有一个与开发者社区分离的独立行业和群体，虽然我们本质上都在讨论代码和漏洞，但一方更关注构建，另一方则更关注攻击和破坏，两者在某种程度上是割裂的。

And and now, you know, stepping a bit back for a moment and looking at the security industries, it's quite fascinating how we have this separated industry and community on the developer community, right, where we both talk about code and bugs, basically, but one side is maybe more about building things and the other about attacking and destroying, and and so they are a bit distinct somehow and separated.

这让我觉得很有意思。

And that's that's interesting to me.

我认为由此产生的一个谬误是：安全行业痴迷于安全问题，然后销售那些承诺'安全可以像产品一样购买'的产品。

And I think one fallacy that comes out of this is, you know, that the security industry is all fascinated about the the security problems and then is selling products basically that that that promise, you know, you can have security just as a product.

对吧？

Right?

而且，我是说，这个行业有很多钱可赚，它是由合规性和对数据泄露的恐惧驱动的。

And and, I mean, there's a lot of money in that industry, and it's it's driven by, you know, compliance and fear of data breaches.

所以我认为作为CISO，你会很难决定该使用和购买什么产品。

And and so I think as a CISO, you have a hard time knowing, you know, what product should I should I use and and and buy.

我认为这里常犯的错误是把安全视为产品，而不是将其构建到开发流程中。

And often, I think a mistake here is to to look at security as a product and not as something that you are building into the process of development.

对吧？

Right?

因为我认为现实中，这才是你必须做的——而不是拥有一个工具，在你点击扫描按钮后又找出1000个问题。

Because I think in reality, that's that's what you must do and not have a tool that finds you yet another 1,000 issues if you hit the scan button.

对吧？

Right?

而是应该将安全嵌入流程中发现问题，然后让开发人员参与并帮助修复问题，我认为这才是最大的误区。

But something that embeds into the process finding issues, but then engaging developers and and and helping you fix things, and I think that's the the biggest fallacy to me.

我们之前可能讨论过随之而来的责任归属问题。

We talked about the the ownership that comes with that maybe.

对吧？

Right?

我认为安全领域存在某种神秘感，让人觉得只有顶尖黑客专家才能掌控，但实际上界限要模糊得多。

I think there is a bit of this mysterium about security, and it can only be owned by experts who are top notch hackers, etcetera, where I think the lines are a bit more blurry here.

更重要的是修复问题，而非总是聚焦在安全行业热衷讨论的漏洞利用阶段。

And it's it's more about fixing things and not just so much about the exploitation stage all the time that the security industry talks about and and finds fascinating.

我自己也对此深感着迷，不得不承认这点。

And I myself, you know, am guilty here and and find fascinating.

最后一点或许是：不存在完美的安全性。

Lastly, maybe this, you know, that there is no perfect security.

如果你了解安全行业就会明白，追求完美安全本身就是个谬误——很遗憾，完美安全并不存在。

If you get the understanding of the security industry, then maybe that's a fallacy here that, you know, there's no perfect security, unfortunately.

是的。

Yeah.

关于厂商销售产品时承诺能让你的组织安全无忧这件事。

This this thing about vendors selling products promising, you know, your your your organization will be secure.

你的代码会变得安全。

Your code will be secure.

没错。

It's right.

而事实上，现实情况要复杂得多，事情并非如此简单。

And and the fact that the reality is a lot more, it it doesn't really work like that.

你需要团队，需要真正关心安全的人。

Like, you need teams, you need people who care about it.

有时候，我想，一个完全不使用安全工具的团队也能产出非常安全的代码，因为他们都是经验丰富的工程师，或者在他们熟悉的领域工作。反过来也同样成立。

Sometimes you can, I guess, you can have a team that uses zero security tools producing really secure code because they're just experienced engineers or working in the domain that they understand, and you can have the other way around as well?

你可能有一个配备了各种扫描工具的团队，但他们的代码质量依然不高，甚至存在安全隐患。

Like, you can have a team that has all these scanners and whatever, and their code is is still, like, not great not good and unsecure.

这让我想起开发者生产力这个术语，比如我的工程师们效率如何？

It reminds me of the developer productivity term, like, how productive are my engineers?

而且，又有供应商在推销各种工具，声称只要衡量这个指标就能得到那个结果。

And, again, there's vendors selling all these tools saying, hey, measure this and you will get this.

我们看到的还是同样的套路。

And we just see the same thing.

所以我在想，是不是有些事情本身就很难，因为涉及太多变数。

So, I I wonder if it's just a thing of there are just some things that are just hard because there's a lot of moving parts.

你无法只衡量单一指标，因为我们可以针对它优化，但最终结果还是

You cannot just measure just one thing because we can optimize for that and still the outcome will

不尽如人意。

not be great.

我在想是否某些领域就是如此。

I wonder if there's just some areas.

比如开发者生产力是一个，安全性也是。

You know, developer productivity is one, security.

也许软件开发本身就是件难事。

Maybe software is just hard.

确实如此。

It is.

对吧？

Right?

我认为你写的软件越复杂，每个开发者都明白这一点。

I I think the more complex software you write, it's and every developer knows this.

对吧？

Right?

问题越多，难题越多，bug也越多，遇到的安全问题自然也就越多，这是不可避免的。

The the more problems you have, hard problems you have, you know, bugs you have, and also the the more security problems you will run into, and that's just natural.

我们在Sona有一支优秀的漏洞研究团队，他们专门挑选全球最流行的开源项目——那些部署广泛、拥有优秀社区和维护者、设有漏洞赏金计划的项目。

We, you know, we have a great vulnerability research team at Sona, and and so those guys are they are picking the the most popular open source projects in the world that are, you know, deployed everywhere with great communities, great maintainers, bug bounty programs where people get paid if they find something, etcetera.

这让我觉得非常有意思。

And it's fascinating to me.

每次他们选择这类高关注度的目标，总能有所发现。

Every time they choose such a, you know, high profile target, they go in and they still find something.

对吧？

Right?

如果你有足够的动力，并且足够仔细地寻找，我认为总能发现些什么。

If you, you know, if you're motivated enough and, you know, look hard enough, I I I think you you can find something.

不幸的是，这就是现实。

And and, unfortunately, that's that's that's the that's the reality.

对吧？

Right?

作为一名从业二十年的软件安全专业人士，您能给我这个工程师什么建议？

As a software professional, as a security professional in the field for twenty years, what can you advise to me as an engineer?

我如何知道我的软件足够安全？或者说应该在什么时候停止追求完美？

How can I know that my software is secure enough or at what point should I stop?

您会如何看待这个问题？

And how would you think about this?

显然，个人开发者、小型企业、中型公司和大型企业的情况会有所不同。您会建议工程师如何考量'足够好'的安全标准？

Obviously, there will be differences between if I'm a one person, you know, tiny business, a mid sized company at a very large company, how would you advise engineers to think about, you know, good enough security?

好的。

Okay.

我可以继续了。

I can move on.

这很好。

This is good.

我们来做其他事情吧。

Let's let's do the other stuff.

是的。

Yeah.

这很棘手，因为我们说过完美的安全性很难实现，但问题是：什么是足够好？你该如何解决这个问题？

It's tough because we said it's it's you know, perfect security is is is hard, but then to the question, what is good enough and and how can you solve this?

我认为使用工具是你应该做的第一件事。

I think using tools is a is the first thing you you you should use.

对吧？

Right?

我认为，这有点像保护你的房子。

I I think, you know, it's like a bit like securing your house.

对吧？

Right?

就像，你应该确保关好门窗并保持基本的安全习惯。

Like, you should make sure you shut your windows and doors and have some basic hygiene.

这并不意味着一个技术高超或资金充足的攻击者无法闯入，但你可以确保自己关好了那些门窗。

It doesn't mean that a, you know, highly skilled or funded attacker can break in, but you can make sure you you shut those windows and doors.

我认为在软件领域，挑战在于你每天都在新增门窗，基本上就是随着新功能的添加，所以我认为你需要一些自动化工具来确保基础安全，然后我建议可以先做一个初步评估。

I think with software, the the challenge is a bit you're adding new windows and doors every day, basically, like with the new features you're adding, and so I think you need some automation for that to have your basics right, and then I would recommend, basically, you can start with a initial assessment.

我目前处于什么水平？

Where where am I standing today?

对吧？

Right?

比如，你可以聘请专业人士，或者使用工具来评估当前的状况，找出最需要解决的关键问题并修复它们。

Like, you can hire professionals or, you know, use a tool for this and kind of, like, assess where do I stand today, what are my most critical issues I should fix, and and get them fixed.

更重要的是，在你添加功能和编写代码时，要确保不会在此基础上引入更多问题。

And then more importantly, as you're adding features and as you're coding, making sure you're not adding more on top of that.

对吧？

Right?

确保你不会增加更多的安全漏洞，同时也不会引入更多技术债务和质量问题，这些问题长期来看会导致安全隐患。

Making sure you're not adding more security vulnerabilities, and, also, you're not adding more technical depth that and and quality problems that in the long run lead to security issues.

我认为在这里自动化是关键。

And I think here automation is key, basically.

然后，大概一个季度后，你可以再次运行评估，看看自己处于什么位置。

And then, you know, after a quarter or something, you can run that assessment again and and look at where am I standing.

希望作为开发者的你一直高效工作，添加新功能没有拖慢进度，同时也在那个时间点提升了安全防护水平。

And, hopefully, you have been, you know, very productive as a developer and adding new features didn't slow you down, but, also, you you increased your security posture at that point.

这是个永无止境的故事，而且是个不断发展的领域。

That's a never ending story, and and it's a growing field.

对吧？

Right?

比如，我们始终需要关注最新的变化。

Like, we always need to be aware of the latest changes.

现在，关于语言模型和提示注入攻击，你可能需要自问——作为Mike，如果我基于语言模型开发或调用API，它们能防范这些风险吗？

Right now, LMs and prompt injections, you'll probably need to ask yourself as as Mike if I'm building on top of LMs or I'm invoking APIs, can they go in there?

然后，你知道的，新问题会不断涌现，一个接一个。

And then, you know, the next thing will come out come again, and the next and the next and the next.

我觉得关注OWASP十大安全风险总没错，至少能覆盖最基础的防护。

I I guess keeping an eye on the OWASP top 10 is never a bad thing, just to cover the very basics.

没错。

Yep.

我同意。

I agree.

现在作为结束问题，我要让你当场作答了。

Now, as a closing question, I'm gonna put you on the spot here.

你认为哪种编程语言最安全？

Which programming language do you think is the most secure?

那种让你无论是使用还是观察时都感到非常满意的语言，它本身似乎从一开始就能帮助预防许多安全问题。

The the the one that you you are very happy either is using it or observing as, like, okay, this is the language itself seems to help prevent a bunch of security issues to start with.

我认为新语言更安全。

I think the newer languages are more secure.

我我喜欢，Go语言就是个很好的例子。

I I like, Gov is a is a is a good example.

我认为，默认情况下，新语言从旧语言中吸取了教训，表现得更为强大，但其他语言也在不断进化。

I think, you know, by default, things are just, you know, new languages learned from the past, from from older languages, would go strong, but I think also other languages are evolving.

我觉得Java在企业中很常见，我认为它相当安全。

I think Java is you know, we see that a lot in enterprises, and I think it's it's quite secure to use.

所以这就是我的答案。

So so that would be my answer here.

不。

No.

我我我很高兴你提到了Go语言。

I I I like that you dropped Go.

它在初创企业中获得了相当不错的反响，包括目前甚至用于构建网页应用。

It's it's it's getting pretty good traction with startups as well, including, for now, even building web stuff.

它的势头正在上升。

It's it's picking up.

所以我想这归根结底取决于人们的喜好，但听到这些很好。

So it's I I guess it's all all all down to people's tastes, but it's good to hear.

那么，约翰尼斯，这次谈话真的很有趣。

So, Johannes, this was really interesting.

感谢你参加播客。

Thanks for coming on the podcast.

是的。

Yeah.

谢谢。

Thank you.

很荣幸能来到这里，感谢邀请。

My pleasure to be here, and thanks for the invite.

非常感谢这次交流。

Well, thanks very much for this.

特别感谢约翰内斯带我们深入探讨代码安全这个话题。

Thanks a lot to Johannes for taking us deeper into the topic of code security.

我觉得最有趣的是，要准确定义什么使代码安全是如此困难，因为存在太多潜在的攻击途径。

The thing that I found the most interesting is just how hard it is to define exactly what makes code secure because there are simply so many impossible attack vectors.

从使用被入侵的依赖包，到AI生成的代码存在明显安全漏洞（如未验证输入），再到意外泄露凭证，问题层出不穷。

From using a dependency that gets compromised, to AI generating code with clearing security vulnerability, like not validating inputs, to accidentally leaking credentials, the list just goes on.

安全就像是贯穿软件的无形之物。

Security feels like this invisible thing across software.

只要没有发现安全问题，它就不会引起太多关注。

As long as there's no security issues discovered, it doesn't get much attention.

但一旦出现问题，就会陷入手忙脚乱的应对状态。

But once there is, then there's a scramble on what to do.

作为专业软件工程师，我们需要持续关注常见安全漏洞及防御措施，包括AI工具带来的新型威胁。

As a professional software engineer, we need to keep up to date with common security vulnerabilities and how we can defend against them, including the new ones that AI tools introduce.

更多关于安全工程的细节，请查看节目说明中链接的《务实工程师》深度解析。

For more details on security engineering, see the Pragmatic Engineer deep dives linked in the show notes below.

如果你喜欢这期播客，请在您喜爱的播客平台和YouTube上订阅。

If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube.

如果你能给节目评分，我们将特别感谢。

A special thank you if you also leave a rating on the show.

感谢收听，我们下期节目再见。

Thanks and see you on the next one.