Zum Hauptinhalt springen
Elementary Threat · BSI IT-Grundschutz

G 0.28 — Software Vulnerabilities or Errors

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.6A.5.7A.5.14A.5.15A.5.29A.5.34A.5.35A.7.13A.8.1A.8.3A.8.4A.8.5A.8.7A.8.8A.8.9A.8.14A.8.16A.8.19A.8.20A.8.21A.8.24A.8.25A.8.26A.8.27A.8.28A.8.29A.8.30A.8.31A.8.32A.8.33 BSI IT-GrundschutzISO 27001ISO 27002

Most security advisories issued by Computer Emergency Response Teams (CERTs) in recent years share a common cause: programming errors. A single buffer overflow in a widely used library can leave thousands of organisations vulnerable simultaneously — regardless of industry, size or location.

Software vulnerabilities and errors (G 0.28) are among the most frequently exploited threat categories. The complexity of modern software makes it virtually impossible to detect all bugs before release. Attackers know this — and systematically exploit it.

What’s behind it?

Every piece of software contains bugs — and the more complex it is, the more bugs it has. Intensive testing before release reduces the count but never eliminates them completely. Security-relevant bugs arise where inputs are not adequately validated, memory is not correctly managed or permission checks are incorrectly implemented.

Vulnerability types

  • Memory corruption (buffer overflows) — By far the most common type of vulnerability in C/C++-based applications. An attacker writes beyond the boundary of a memory area and can thus execute their own code.
  • Injection vulnerabilitiesSQL injection, command injection and similar attacks inject commands through input fields that the application passes unfiltered to the database or operating system.
  • Authentication and authorisation flaws — Faulty session management, hard-coded credentials, inadequate permission checks.
  • Logic errors — The application behaves technically correctly, but the business logic contains gaps that can be exploited (e.g. negative order quantities that result in credits).
  • Cryptographic weaknesses — Use of outdated algorithms, faulty implementation or inadequate key management.

Impact

Software vulnerabilities are the most common entry point for targeted attacks. Through a single vulnerability in an internet-exposed system, an attacker can gain access to the entire internal network. Browser vulnerabilities are particularly critical because browsers are used for both internet access and internal web applications and are installed on practically every workstation.

Practical examples

VPN gateway with known vulnerability. A company runs a VPN gateway for which a security patch has been available for months. The patch was scheduled in change management but repeatedly deferred. Attackers systematically scan for this vulnerability, find the unprotected system and use it as an entry point into the corporate network.

Vulnerability in an internal web application. A custom-developed HR application validates user input inadequately. An SQL injection attack via the search field gives access to the entire personnel database — including salary information, social security numbers and performance reviews.

Outdated library in the build process. A development team uses an open-source library for XML parsing that has been known to be vulnerable for more than a year. The dependency was introduced during initial development and has never been updated since. An attacker exploits the vulnerability via a manipulated import file.

Relevant controls

The following ISO 27001 controls mitigate this threat. (You’ll find the complete list of 30 mapped controls below in the section ‘ISO 27001 Controls Covering This Threat’.)

Prevention:

Detection:

Response:

BSI IT-Grundschutz

G 0.28 is linked by the BSI IT-Grundschutz catalogue to the following modules:

  • CON.8 (Software development) — Requirements for secure software development.
  • CON.10 (Development of web applications) — Specific requirements for the security of web applications.
  • OPS.1.1.3 (Patch and change management) — Processes for the timely distribution of security patches.
  • APP.4.6 (SAP ABAP programming) — Example of application-specific development guidelines.

Sources

ISO 27001 Controls Covering This Threat

A.5.6 Contact with special interest groups A.5.7 Threat intelligence A.5.14 Information transfer A.5.15 Access control A.5.29 Information security during disruption A.5.34 Privacy and protection of PII A.5.35 Independent review of information security A.7.13 Equipment maintenance A.8.1 User endpoint devices A.8.3 Information access restriction A.8.4 Access to source code A.8.5 Secure authentication A.8.7 Protection against malware A.8.8 Management of technical vulnerabilities A.8.9 Configuration management A.8.14 Redundancy of information processing facilities A.8.16 Monitoring activities A.8.19 Installation of software on operational systems A.8.20 Networks security A.8.21 Security of network services A.8.24 Use of cryptography A.8.25 Secure development life cycle A.8.26 Application security requirements A.8.27 Secure system architecture and engineering principles A.8.28 Secure coding A.8.29 Security testing in development and acceptance A.8.30 Outsourced development A.8.31 Separation of development, test and production environments A.8.32 Change management A.8.33 Test information

Frequently asked questions

What is the difference between a vulnerability and a bug?

A bug is a general programming error that causes unexpected behaviour. A vulnerability is a bug with security relevance -- it can be exploited by an attacker to gain unauthorised access to data, execute code or take over systems. Every vulnerability is a bug, but far from every bug is a vulnerability.

Why is vulnerability management so time-critical?

Between the disclosure of a vulnerability and the first active attacks, only hours sometimes pass. Attackers automatically scan the internet for vulnerable systems. A patch applied only weeks after disclosure offers no protection against attackers who strike the day after the advisory.

Can custom-developed applications also be affected?

Custom software is particularly at risk because it is not subject to the same external review processes as widely used standard software. Security testing (SAST, DAST), code reviews and adherence to secure development guidelines (Secure SDLC) are therefore crucial.