Krutikp/ComplianceLLM huggingface dataset:
CWE-477: Use of Obsolete Function (Base)

Description: The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.

Extended Description: As programming languages evolve, functions occasionally become obsolete due to: Advances in the language Improved understanding of how operations should be performed effectively and securely Changes in the conventions that govern certain operations Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Quality Degradation::

Detection Methods: ::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Binary / Bytecode Quality Analysis Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Debugger:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source Code Quality Analyzer Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:High::METHOD:Automated Static Analysis:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Origin Analysis:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Refer to the documentation for the obsolete function in order to determine why it is deprecated or obsolete and to learn about alternative ways to achieve the same functionality.::PHASE:Requirements:DESCRIPTION:Consider seriously the security implications of using an obsolete function. Consider using alternate functions.::
CWE-478: Missing Default Case in Multiple Condition Expression (Base)

Description: The code does not have a default case in an expression with multiple conditions, such as a switch statement.

Extended Description: If a multiple-condition expression (such as a switch in C) omits the default case but does not consider or handle all possible values that could occur, then this might lead to complex logical errors and resultant weaknesses. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system.



Applicable Platforms: ::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C#:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Python:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:JavaScript:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Integrity:IMPACT:Varies by Context:IMPACT:Alter Execution Logic:NOTE:Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Ensure that there are no cases unaccounted for when adjusting program flow or values based on the value of a given variable. In the case of switch style statements, the very simple act of creating a default case can, if done correctly, mitigate this situation. Often however, the default case is used simply to represent an assumed option, as opposed to working as a check for invalid input. This is poor practice and in some cases is as bad as omitting a default case entirely.::
CWE-480: Use of Incorrect Operator (Base)

Description: The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.

Extended Description: These types of errors are generally the result of a typo by the programmer.



Applicable Platforms: ::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Sometimes::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Sometimes::LANGUAGE NAME:Perl:LANGUAGE PREVALENCE:Sometimes::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Alter Execution Logic:NOTE:This weakness can cause unintended logic to be executed and other unexpected application behavior.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can be found easily using static analysis. However in some cases an operator might appear to be incorrect, but is actually correct and reflects unusual logic within the program.::METHOD:Manual Static Analysis:DESCRIPTION:This weakness can be found easily using static analysis. However in some cases an operator might appear to be incorrect, but is actually correct and reflects unusual logic within the program.::


Observed Examples: ::REFERENCE:CVE-2022-3979:DESCRIPTION:Chain: data visualization program written in PHP uses the != operator instead of the type-strict !== operator (CWE-480) when validating hash values, potentially leading to an incorrect type conversion (CWE-704):LINK:https://www.cve.org/CVERecord?id=CVE-2022-3979::REFERENCE:CVE-2021-3116:DESCRIPTION:Chain: Python-based HTTP Proxy server uses the wrong boolean operators (CWE-480) causing an incorrect comparison (CWE-697) that identifies an authN failure if all three conditions are met instead of only one, allowing bypass of the proxy authentication (CWE-1390):LINK:https://www.cve.org/CVERecord?id=CVE-2021-3116::
CWE-483: Incorrect Block Delimitation (Base)

Description: The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.

Extended Description: In some languages, braces (or other delimiters) are optional for blocks. When the delimiter is omitted, it is possible to insert a logic error in which a statement is thought to be in a block but is not. In some cases, the logic error can have security implications.



Applicable Platforms: ::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Sometimes::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Sometimes::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Alter Execution Logic:NOTE:This is a general logic error which will often lead to obviously-incorrect behaviors that are quickly noticed and fixed. In lightly tested or untested code, this error may be introduced it into a production environment and provide additional attack vectors by creating a control flow path leading to an unexpected state in the application. The consequences will depend on the types of behaviors that are being incorrectly executed.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Always use explicit block delimitation and use static-analysis technologies to enforce this practice.::

Observed Examples: ::REFERENCE:CVE-2014-1266:DESCRIPTION:incorrect indentation of goto statement makes it more difficult to detect an incorrect goto (Apple's goto fail):LINK:https://www.cve.org/CVERecord?id=CVE-2014-1266::
CWE-484: Omitted Break Statement in Switch (Base)

Description: The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.

Extended Description: This can lead to critical code executing in situations where it should not.



Applicable Platforms: ::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C#:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:PHP:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Alter Execution Logic:NOTE:This weakness can cause unintended logic to be executed and other unexpected application behavior.::

Detection Methods: ::METHOD:White Box:DESCRIPTION:Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected product behavior is required to interpret whether the code is correct.::METHOD:Black Box:DESCRIPTION:Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities.::PHASE:Implementation:DESCRIPTION:The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.::
CWE-487: Reliance on Package-level Scope (Base)

Description: Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.

Extended Description: The purpose of package scope is to prevent accidental access by other parts of a program. This is an ease-of-software-development feature but not a security feature.



Applicable Platforms: ::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:Any data in a Java package can be accessed outside of the Java framework if the package is distributed.::SCOPE:Integrity:IMPACT:Modify Application Data:NOTE:The data in a Java class can be modified by anyone outside of the Java framework if the packages is distributed.::


Potential Mitigations: ::PHASE:Architecture and Design Implementation:DESCRIPTION:Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering.::
CWE-488: Exposure of Data Element to Wrong Session (Base)

Description: The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.

Extended Description: Data can bleed from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool. In the case of Servlets, developers sometimes do not understand that, unless a Servlet implements the SingleThreadModel interface, the Servlet is a singleton; there is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads. A common result is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:Protect the application's sessions from information leakage. Make sure that a session's data is not used or visible by other sessions.::PHASE:Testing:DESCRIPTION:Use a static analysis tool to scan the code for information leakage vulnerabilities (e.g. Singleton Member Field).::PHASE:Architecture and Design:DESCRIPTION:In a multithreading environment, storing user data in Servlet member fields introduces a data access race condition. Do not use member fields to store information in the Servlet.::
CWE-489: Active Debug Code (Base)

Description: The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.

Extended Description: A common development practice is to add back door code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the product. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the product.


Alternate Terms: ::TERM:Leftover debug code:DESCRIPTION:This term originates from Seven Pernicious Kingdoms::

Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation:NOTE:In web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, this oversight during the software process allows attackers access to debug functionality.::PHASE:Build and Compilation::PHASE:Operation::



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Other:IMPACT:Bypass Protection Mechanism:IMPACT:Read Application Data:IMPACT:Gain Privileges or Assume Identity:IMPACT:Varies by Context:NOTE:The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Build and Compilation Distribution:DESCRIPTION:Remove debug code before deploying the application.::




Notes: ::TYPE:Other:NOTE:In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.::
CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere (Base)

Description: The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.

Extended Description: Network-based products, such as web applications, often run on top of an operating system or similar environment. When the product communicates with outside parties, details about the underlying system are expected to remain hidden, such as path names for data files, other OS users, installed packages, the application environment, etc. This system information may be provided by the product itself, or buried within diagnostic or debugging messages. Debugging information helps an adversary learn about the system and form an attack plan. An information exposure occurs when system data or debugging information leaves the program through an output stream or logging function that makes it accessible to unauthorized parties. Using other weaknesses, an attacker could cause errors to occur; the response to these errors can reveal detailed system information, along with other impacts. An attacker can use messages that reveal technologies, operating systems, and product versions to tune the attack against known vulnerabilities in these technologies. A product may use diagnostic methods that provide significant implementation details such as stack traces as part of its error handling mechanism.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Architecture and Design Implementation:DESCRIPTION:Production applications should never use methods that generate internal details such as stack traces and error messages unless that information is directly committed to a log that is not viewable by the end user. All error message text should be HTML entity encoded before being written to the log file to protect against potential cross-site scripting attacks against the viewer of the logs::

Observed Examples: ::REFERENCE:CVE-2021-32638:DESCRIPTION:Code analysis product passes access tokens as a command-line parameter or through an environment variable, making them visible to other processes via the ps command.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-32638::
CWE-501: Trust Boundary Violation (Base)

Description: The product mixes trusted and untrusted data in the same data structure or structured message.

Extended Description: A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary - to move from untrusted to trusted. A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. By combining trusted and untrusted data in the same data structure, it becomes easier for programmers to mistakenly trust unvalidated data.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Architecture and Design::



Common Consequences: ::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::