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.

MISRA

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.

CERT

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

CWE

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.0 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.

CWE/SANS Top 25

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 2019 list on a regular basis with minimal effort.

CVE

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.

CVSS

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.

PCI-DSS

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	Description
6.1	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.
6.2	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.
6.3	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
6.4.3	Production data (live PANs) are not used for testing or development
6.4.4	Removal of test data and accounts from system components before the system becomes active / goes into production
6.4.5.3	Functionality testing to verify that the change does not adversely impact the security of the system.
6.5	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.
6.5.1	Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.
6.5.2	Buffer overflows
6.5.3	Insecure cryptographic storage
6.5.4	Insecure communications
6.5.5	Improper error handling
6.5.6	All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
6.5.7	Cross-site scripting (XSS)
6.5.8	Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).
6.5.9	Cross-site request forgery (CSRF)
6.5.10	Broken authentication and session management.
6.6	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.

SAP-BIZEC

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

WASC

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).

OWASP

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 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.