Compliance Modules

Need to comply with a coding standard? Security Reviewer makes it easy.

Save time by knowing which set standards are being broken and getting insights on how to tackle them.

You can use the following compliance modules to apply coding standards across your codebase. And you’ll get fewer False Positives and False Negatives in your diagnostics. With Security Reviewer, Security By Design will be easy to accomplish in your Security Development Life Cycle. Security Reviewer provides a Qualification Kit for checking our tool at your premises against coding standards as well as OWASP Benchmark and WASC Reports.



Check your code against the MISRA® C and C++ coding standards — automatically.

The MISRA coding rules identify potential issues in safety-critical systems. The MISRA C and C++ compliance modules flag sections of your code that violate these rules, with the support of a bunch of Compilers:

Standards: Posix, C89, C99, C11, C++03, C++11, C++14, C++17

Unix/Linux: GCC, IBM XL C/C++, HP C/aC++, HPE NonStop, Sun Pro C/C++, LLVM Clang

Windows: Visual Studio 2003-2019, Embarcadero

Mac: XCode, LLVM Clang, Digital Mars C/C++, GCC, TryC

Embedded: ARM RealView, ARC MQX Synopsys, Atmel AVR Studio, Atollic True Studio, Avocet ProTools, Batronix uC51, BIPOM Electronics, Byte Craft eTPU C, CCS PIC/dsPIC/DSC, Ceibo-8051C++, CodeWarrior, Cosmic Software, Crossware, ELCC C/C++, GCC C/C++, Green Hills Multi, HighTec C/C++, IAR C/C++, INRIA CompCert, Intel C/C++, Introl C Compiler, Keil ARM C/C++, Mentor Graphic CodeSourcery, Microchip MPLAB, MikrocC Pro, NXP, Renesas HEW, SDCC, Softools Z/Rabbit, Tasking ESD, Texas Instruments CodeComposer, Z World Dynamic C 32, WDC 8/16-bit, Wind River C/C++

The MISRA C compliance module enforces MISRA C:2004 and MISRA C:2012 rules.

The MISRA C++ compliance module enforces MISRA C++:2008 rules.

Security Reviewer identifies MISRA violations with greater accuracy than other tools. And it prioritizes violations based on severity, so you fix the most important issues first.

So, you’ll be able to improve code quality. Plus, you’ll be able to track and report on MISRA (and ISO) compliance.


Check your code against the CERT C, C++, JAVA and CERT Mobile coding standards — automatically.

The CERT coding rules identify security vulnerabilities in your code. The CERT C, C++, JAVA and CERT Mobile compliance modules flag code that violates these rules. This helps you eliminate undefined behaviors and apply best practices for secure code.

Plus, Security Reviewer helps you prioritize and fix the most critical violations first. You’ll even get detailed guidance and examples to help you fix these errors.

So, you’ll develop quality systems that are safe, secure, and reliable. Plus, you’ll be able to track and report on CERT compliance


Check your code against the CWE™ list of security weaknesses — automatically.  

CWE identifies common security weaknesses in all Supported Languages.

The CWE compatibility module identifies code with those security weaknesses, and Security Reviewer prioritizes these CWE 4.6 violations.

This makes it easy for you to fix the most critical errors first. And by using Security Reviewer, you’ll improve overall code security.


The CWE SANS Top 25 Most Dangerous Software Errors is a demonstrative list of the most widespread and critical weaknesses that can lead to serious vulnerabilities in software. These weaknesses are often easy to find and exploit. They are dangerous because they will frequently allow adversaries to completely take over execution of software, steal data, or prevent the software from working. To create the list, the CWE and SANS Institute Teams used a data-driven approach that leverages published Common Vulnerabilities and Exposures (CVE®) data and related CWE mappings found within the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD), as well as the Common Vulnerability Scoring System (CVSS) scores associated with each of the CVEs. A scoring formula was then applied to determine the level of prevalence and danger each weakness presents.

This data-driven approach is used by Security Reviewer to generate a CWE/SANS Top 25 2020 list on a regular basis with minimal effort.


The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities and exposures. The National Cybersecurity FFRDC, operated by the Mitre Corporation, maintains the system, with funding from the National Cyber Security Division of the United States Department of Homeland Security.[1]

The Security Content Automation Protocol uses CVE, and CVE IDs are listed on MITRE's system[2] as well as in the US National Vulnerability Database.

Security Reviewer uses CVE to classify all operation-oriented code issues, scripting-languages (JavaScript, TypeScript, Shell, PowerShell, Ruby, etc.) included.


The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

CVSS is a published standard used by organizations worldwide, and the SIG's mission is to continue to improve it.

Security Reviewer classifies every single vulnerability risk as well as application risk using CVSS 3.1 standard.


The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes.

The PCI Standard is mandated by the card brands but administered by the Payment Card Industry Security Standards Council. The standard was created to increase controls around cardholder data to reduce credit card fraud

Static Reviewer provides PCI-DSS 3.2.1 and 2.0 (for compatibility) reporting for all financial applications it analyzes. Static Reviewer covers the following PCI-DSS requirements:

PCI DSS requirement



Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.


Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendorsupplied security patches. Install critical security patches within one month of release.


Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

  • In accordance with PCI DSS (for example, secure authentication and logging)

  • Based on industry standards and/or best practices.

  • Incorporating information security throughout the software-development life cycle


Production data (live PANs) are not used for testing or development


Removal of test data and accounts from system components before the system becomes active / goes into production

Functionality testing to verify that the change does not adversely impact the security of the system.


Address common coding vulnerabilities in software- development processes as follows:

  • Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.

  • Develop applications based on secure coding guidelines.


Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.


Buffer overflows


Insecure cryptographic storage


Insecure communications


Improper error handling


All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).


Cross-site scripting (XSS)


Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).


Cross-site request forgery (CSRF)


Broken authentication and session management.


For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

  • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

  • Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

PCI-DSS 4.0 is coming on late 2020. We are ready for implementing the new reuirements as soon as it will be available, with no additional costs to the customers.

Changes to PCI DSS’s layout and descriptions v.4.0 will include:

  • More accurate requirement titles

  • Additional direction and guidance provided in the Overview section

  • Requirements organized into Security Objectives

  • Requirements refocused as objective or outcome-based statements

  • Clear identification of Intent (Objective) for each requirement

  • Expanded Guidance

As with previous iterations of the PCI DSS, Security Reviewer expects that there will be a grace period for organizations to comply with the newly defined requirements, and PCI DSS version 3.2.1 will remain valid for a period of time to support organizations transitioning to the new version of the standard.


Security Reviewer supports Most Common SAP Vulnerabilities SAP BIZEC TEC/11, APP/11 and HANA/11.

The business application security initiative is a non-profit alliance that focuses on security defects in SAP business applications.

These applications are responsible for processing and managing the most critical business information and processes, which turns their protection into a key subject for private, governmental and defense organizations around the globe.

These days, many security professionals believe that SAP security is a synonym for "Segregation of Duties" and authorizations. While functional security is highly important, there are many other threats which imply higher levels of risk and are not usually properly assessed. The work of BIZEC is centered on risk rather than on technical details. This enables organizations to understand the impact of application security vulnerabilities and prioritize their mitigation accordingly


The WASC Threat Classification is a cooperative effort to clarify and organize the threats to the security of a web site. The members of the Web Application Security Consortium have created this project to develop and promote industry standard terminology for describing these issues. Application developers, security professionals, software vendors, and compliance auditors using Security Reviewer WASC classification will have the ability to access a consistent language and definitions for web security related issues.

Security Reviewer has been evaluated using Web Application Security Scanner Evaluation Criteria (WASSEC).


The OWASP Application Security Verification Standard (ASVS) is full covered by Security Reviewer. It provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.

Security Reviewer provides classification and reporting for OWASP Top Ten 2021, 2017, 2013 and 2010, as well as for Mobile Top Ten 2016 and 2014. Further, Security Reviewer supports OWASP Security API 2019.

The primary aim of the OWASP Application Security Verification Standard (ASVS) is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard.

Security Reviewer leads on OWASP Benchmark.

DISA Control Correlation Identifier Version 2

Defense Information Systems Agency (DISA) organizations are strictly regulated and must ensure their systems are securely configured and that the systems comply with the applicable security policies.  According to the Information Assurance Support Environment (IASE), who maintains the Control Correlation Identifier (CCI) list, and provides a standard identifier and description for each of the singular, actionable statements that comprise an IA control or IA best practice. CCI bridges the gap between high-level policy expressions and low-level technical implementations. CCI allows a security requirement that is expressed in a high-level policy framework to be decomposed and explicitly associated with the low-level security setting(s) that must be assessed to determine compliance with the objectives of that specific security control. This ability to trace security requirements from their origin (e.g., regulations, IA frameworks) to their low-level implementation allows organizations to readily demonstrate compliance to multiple IA compliance frameworks. CCI also provides a means to objectively rollup and compare related compliance assessment results across disparate technologies. Security Reviewer suite provides references to those controls inside the Reports and the dashboard, Team Reviewer.

NIST Special Publication 800-53 Revision 5

This NIST SP 800-53 database represents the controls defined in NIST SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations. These next generation controls offer a proactive and systematic approach to ensuring that critical systems, components, and services are sufficiently trustworthy and have the necessary resilience. Security Reviewer suite provides references to those controls inside the Reports and the dashboard, Team Reviewer.