Is my code vulnerable?


It is highly unlikely that a company with an online presence won’t own a piece of code (programme) in this day and age. The code could be a html page, SQL script, a shell script or a macro. For every line of code that you write, the chances are high that it can introduce vulnerabilities. For a bad actor, your vulnerability is their strength. Thus, software engineering vulnerabilities and related security standards are enumerated by MITRE as well.

The below Java method was written with a good intent to convert latitude and longitude coordinates to UTM (Universal Transverse Mercator). It accepts coordinates from HTTP requests and executes a program local to the server that performs the transformation. The method passes the coordinates as a command-line option to the external program and will retrieve the transformation results and return the UTM coordinates.


What’s missing? The method does not validate if the coordinate input parameter includes only latitude and longitude. In this case, a malicious user could execute another program local to the application server by appending “&” followed by the command for another program to the end of the coordinate string. The “&” instructs the OS to execute another program.

This is how, unknowingly, the developer of the code introduced a vulnerability with a high Common Vulnerability Scoring System (CVSS) rating.

eg CVSSv3.1: 7.7 [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C]

According to MITRE, in 2021, software and product developers introduced around 1800 vulnerabilities. This is a large number. However, for simplicity, we can categorise them into groups using CWE (Common Weakness Enumeration) or in simple language, I will label them as types of common software bugs.

Before we dive into CWE, let us take a step back and understand what CVEs are and what data fields each CVE record holds.


Common Vulnerability and Exposures or CVE is a list (database) of publicly disclosed computer security vulnerabilities. CVE is sponsored by the U.S. Department of Homeland Security (DHS). Its mission is to identify, define, and catalogue publicly disclosed cybersecurity vulnerabilities. Any vulnerability publicly disclosed will have a CVE Record. It is the descriptive data about a vulnerability associated with a CVE ID and other metadata related to it. Information attached to the CVE record are CVSS v3.1, CVSS v2, CWE, CPE (Common Platform Enumeration) and Reference Link Tags.



CVE Metadata


CPE (Common Platform Enumeration) is a structured naming scheme for information technology systems, software, and packages. Based upon the generic syntax for Uniform Resource Identifiers (URI), CPE includes a formal name format, a method for checking names against a system. CPE is used in CVE Records to help us know what IT assets and their versions are vulnerable. IT management tools can collect information about installed products, identify them using their CPE names, and then use this standardised information to help make fully or partially automated decisions regarding the assets. E.g. identifying the presence of a vulnerable product using a vulnerability management tool that checks the system for known vulnerabilities in the software and triggers a configuration management tool to verify that the software is configured securely according to the organisation’s policies.

The CPE has gone through multiple revisions and the current version is at 2.3. CPE is an integral building block of the Security Content Automation Protocol (SCAP) and OpenSCAP is an OpenSource implementation of it. It helps perform and enforce security baselines with ease and reduces the costs of performing security audits. Previously, I have heavily relied on CPEs and SCAP to develop a vulnerability management tool. The CPENameMatcher code  used in it helps to identify vulnerable products. This is an implementation of the NIST’s CPE Matching algorithm. It is a C# code transcoded by me from Java Implementation written by Joshua Kraunelis.





The Common Vulnerability Scoring System is the industry standard for scoring CVEs. A score of 10 is the most severe. CVSS consists of three metric groups: Base, Temporal, and Environmental. The Base metrics produce a score ranging from 0 to 10. The Base Score reflects the severity of a vulnerability according to its intrinsic characteristics, which are constant over time. The Base score is then modified by scoring the Temporal and Environmental metrics. The Temporal metric group represents changes over time due to events external to the vulnerability but not across user environments. The Environmental metric group represents the characteristics of a vulnerability that are relevant and unique to a particular user’s environment. I am yet to come across this unicorn organisation that has implemented an Environmental metric group. This is dependent on the maturity of the organisation’s vulnerability management. CVSS has gone through multiple revisions/versions to reflect the actual severity better.

Here’s an extract from an Open Letter sent to FIRST (CVSS Special Interest Group) by the Open Security Foundation explaining the shortcomings of CVSS V2.


The 4th Level Granularity Consideration 

The current 3-level scoring system simply does not add sufficient granularity to vulnerability scoring. While CVSS technically provides scoring between 0.0 to 10.0, it is based on a 3-level system. This leads to disparate vulnerabilities ultimately receiving the same score, because that score is derived from a limited number of variables.”




CWE (Common Weakness Enumeration) is a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and a baseline for weakness identification, mitigation, and prevention efforts. CWE is a formal list of common software and hardware weaknesses in architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created as a common language for categorising security weaknesses for weakness identification, mitigation, and prevention efforts. Every time a vulnerability is publicly disclosed, the weakness that caused it is listed along with the vulnerability.




  • CWE-126: Buffer Over-read that led to heartbleed bug in OpenSSL in the year 2014.
  • CWE-502: Deserialization of Untrusted Data that caused Log4Shell Bug in the year 2021.

CWE Focus List

MITRE released the 2021 CWE Top 25 using published vulnerability data from the National Vulnerability Database( NVD). NVD contains vulnerability data from CVE, additional analysis and information mapping to one or more weaknesses, and a CVSS score representing the potential severity,  based upon a standardised set of characteristics about the vulnerability.

MITRE takes a data-driven approach in creating the 2021 CWE Top 25. What does this mean to software developers? That means we focus on the top 25 exploited software weaknesses and make ourselves aware of mitigation strategies.

Focusing on all 25 in one article would be too long an article. So, we will break this into a three-part series, each focusing on ~8 CWEs.



Now that we have covered the standards and core fundamentals, we can move into secure software engineering practices – this will be the focus of my next blog. Before we close off, here’s some food for thought:

“Introduction of software weaknesses can not only be introduced at the implementation stage but it’s possible to introduce it during the architecture and design phase too”.

As software engineers and architects, it is important to familiarise ourselves with the upcoming vulnerability landscape and software weaknesses and what steps can we take to overcome them.

Author: Subodh Chettri

References & Further Reading

Tsipenyuk, K, Chess, B & McGraw, G 2005, “Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors,” IEEE Security and Privacy Magazine, vol. 3, no. 6, pp. 81–84.

Chettri, S. (2021, October 30). SubodhChettri/CPE-Naming-and-Matching-Algorithms. GitHub.

Cheikes, B. A., Waltermire, D., & Scarfone, K. (2011). Common platform enumeration : National Institute of Standards and Technology.

Andrew Buttner. (2008). Enumerations – CPE, CVE, CCE : MITRE .

Editor, C. C. (n.d.). CVE Record Metadata – Glossary | CSRC. Retrieved from

Bart van Dongen. 202. Designing structured metadata for CVE reports: University of Amsterdam.

Cheikes, B. A., Waltermire, D., & Scarfone, K. (2011). Common platform enumeration : National Institute of Standards and Technology.

Parmelee, M. C., Booth, H., Waltermire, D., & Scarfone, K. (2011). Common platform enumeration : National Institute of Standards and Technology.

‌Computer Security Division, I. T. L. (2016, December 7). Common Platform Enumeration (CPE) – Security Content Automation Protocol | CSRC | CSRC. Retrieved from CSRC | NIST website:

CPE – Common Platform Enumeration: CPE Specifications. (n.d.). Retrieved from website:

Carsten Eiram, Risk Based Security and Brian Martin.2013. Open Security Foundation: The CVSSv2 Shortcomings, Faults, and Failures Formulation

Mastering CVSS v3.1. (n.d.). Retrieved from website:

Computer Security Division, I. T. L. (2016, December 7). Security Content Automation Protocol | CSRC | CSRC. Retrieved from CSRC | NIST website:

CWE – CWE-78: Improper Neutralization of Special Elements used in an OS Command (“OS Command Injection”) (4.2). (n.d.). Retrieved from website:

Difference between CWE & CVE. (n.d.). Retrieved from website:

What Is CVSS v3.1? Understanding The New CVSS. (n.d.). Retrieved from WhiteSource website:

NVD – CVSS v3 Calculator. (n.d.).