From Code Quality to Total Security

2021年7月16日

If software defects are the doors used by hackers, then code quality must be improved to address the issue. But first, how big is the problem, and how can it be fixed?

Shawn Prestridge

Related To: IAR Systems

This article series is in the改善软件代码质量topic within ourSeries Library

What you'll learn:

Security issues go beyond buffer overflows.
How standards help with commonly exploited weaknesses.
通过代码分析工具改善代码质量和安全性。

Poor code quality is actually a widespread problem and quite a bit ofevidence 支持声称,糟糕的编码页ractices lead directly to vulnerabilities. While this isn’t new, perhaps the first time that people truly became aware of it was in 2001 when the Code Red worm exploited a buffer overflow attack on Microsoft’s Internet Information Services (IIS).¹Although the first documented buffer overflow attack was in 1988 on the Unix finger command, it was limited greatly in its ability to affect the general population. Thus, it didn’t make headlines.

另一方面，由于红色代码导致了大规模的Internet放缓，并被新闻媒体广泛覆盖，因此我们发现，在一夜之间，缓冲区溢出攻击的普遍增加。似乎安全的研究人员和黑客都在各个地方都在各种系统（包括嵌入式系统）中发现这些错误。

这种类型的攻击使黑客可以通过针对使用固定长度缓冲区保存文本或数据的任何代码来运行他们想要在受影响系统上的任何代码。黑客将缓冲空间填充到最大值，然后在合法缓冲区空间的末尾写入可执行的代码。受到攻击的系统在缓冲区末尾执行代码，在许多情况下，攻击者可以执行他们想要的任何事情。²

Such an attack gained urgency because it wasn’t common coding practice to check and enforce the limits of buffers. Now, many coding standards like the Common Weakness Enumeration frommitre.orgrecommend checking buffers for this type of vulnerability.³

不幸的是，在编写代码时，开发人员寻找此问题仍然不是常见的做法。通常需要使用代码分析工具来找到这些问题并提醒开发人员有一个问题，因此他们可以解决问题。由于这样的简单代码质量改进可以消除最常见的黑客方法之一，因此它极大地提高了代码的安全性。因此，良好的编码实践是检查和执行代码中的缓冲区长度。

Not Just Buffer Overflows

Don’t misunderstand, the problem isn’t simply buffer overflows. It’s actually a systemic problem: Sloppy coding practices, in general, lead to a countless number of security holes that hackers can utilize to compromise a system. A paper published by the Software Engineering Institute (SEI) puts it in very clear words:

“…质量性能指标为确定非常高质量的产品并预测安全和安全结果的背景。许多常见的弱点枚举（CWE），例如不当使用编程语言构建体，缓冲区溢出以及未能验证输入值的失败可能与质量差的编码和开发实践有关。提高质量是解决某些软件安全问题的必要条件。⁴“

该论文继续表明安全问题（其中许多是由货物软件引起的），可以像更普通的编码缺陷一样对待。结果，应用传统的质量保证技术将有助于解决其中一些安全问题。

正常的软件质量保证过程you to estimate the number of defects remaining in the system. Can the same be done with security vulnerabilities? While the SEI stops short of confirming a mathematical relationship between code quality and security, they do state that 1% to 5% of software defects are security vulnerabilities. According to SEI, their evidence indicates that when security vulnerabilities are tracked, they could accurately estimate the level of code quality in the system.⁴

This conclusively shows that code quality is a necessary (but not sufficient) condition for security. It really disproves the notion that security can be treated as a bolt-on at the end of development. Rather, security must be threaded through the DNA of a project, from design, to code, and all the way to production.

Coding Standards Help

许多最常见的安全漏洞都在编码标准中解决了，例如常见的弱点（CWE）mitre.org。They point out additional areas of concern like divide-by-zero, data injection, loop irregularities, null pointer exploits, and string parsing errors. MISRA C and MISRA C++ also promote safe and reliable coding practices to prevent security vulnerabilities from creeping into code.

尽管这些可以捕获许多常见的弱点，但开发人员在编写代码时必须思考更大（图。1）: How can a hacker exploit what I just wrote? Where are the holes? Am I making assumptions about what the inputs will look like and how the outputs will be used?

A good rule-of-thumb to follow is that if you’re making assumptions, then those assumptions should be turned into code that ensures what you’re expecting is actually what you’re getting. If you don’t do it, then a hacker will do it for you.

But what about open-source software? The typical argument for using open-source components in a design relies on the “proven in use” argument: So many people use it, it must be good. In the same paper, the SEI has addresses this:

“除了自由之外，吹捧开源的好处之一是假设‘在源代码上拥有许多眼睛意味着可以快速发现安全问题，任何人都可以修复错误；但是，您不依赖供应商。’但是，现实是，如果没有纪律严明且一致地关注删除缺陷，安全错误和其他错误将在代码中。⁴“

换句话说，SEI说“使用中的证明”论点没有任何意义。它呼唤有关任何人，某人，没有人和所有人的故事，因为它将质量保证应用于开源代码。此外，测试不足以证明代码。

The SEI says that code-quality standards like the CWE find issues in code that typically never get detected in standard testing and usually only are found when hackers exploit the vulnerability.⁴To prove that point, in May 2020, researchers from Purdue University demonstrated 26 vulnerabilities in open-source USB stacks that are used in Linux, macOS, Windows, and FreeBSD.⁵When it comes to security, code quality is key andallcode matters.

代码分析工具有助于遵守标准

软件工程师可以如何解决代码质量并提高应用程序安全性？简单的答案是使用代码分析工具，这些工具具有两种基本口味。静态分析仅查看应用程序的源代码。运行时（或动态）分析仪器代码寻找诸如无指针和数据注入方法之类的弱点（图2）。

High-quality code-analysis tools include checks for CWE, MISRA, and CERT C. CERT C is another coding standard designed to promote secure coding practices. These three rulesets together form a great combination of coding practices that promote security. Some rulesets overlap with others, but also provide some unique features to help ensure the code has a high degree of security. Furthermore, using these standards helps to ensure the best possible code quality. And they might even find some latent defects in the code.

High-Quality Code is Secure Code

You can’t have security unless you have code quality, and you can’t pass the code quality buck onto someone else because their bugs are likely to become your security nightmare. There’s hope because code-analysis tools can help you quickly identify issues before they bite you.

通往安全之路总是通过代码质量的门户。

从改善软件代码质量series within ourSeries Library