Team Reviewer provides an effective vulnerability discovery & tracking, by continuously identifying threats, monitoring changes in your apps, discovering and mapping all your devices and software — including new, unauthorized and forgotten ones —, and reviewing configuration details for each asset.

Open

Team Reviewer allows y'all to deal your application safety program, hold production in addition to application information, schedule scans, triage vulnerabilities in addition to force findings into defect trackers. Consolidate your findings into source of truth amongst Team Reviewer.

Central Repository

Team Reviewer has the ability to maintain its own repository of internally discovered vulnerabilities (findings). The private repository behaves identical to other sources of vulnerability intelligence such as the OSS Index, VulnDB, NVD, etc.

This repository can be stored to MySQL, MariaDB, PostGres or Oracle (RAC included) DMBS, or to a Managed database service (AWS RDS).

There are three primary use cases for the private vulnerability repository.

• Organizations that wish to track vulnerabilities in internally-developed components shared among various software projects in the organization.

• Organizations performing security research that have a need to document said research before optionally disclosing it.

• Organizations that are using unmanaged sources of data to identify vulnerabilities. This includes:

  • Change logs

  • Commit logs

  • Issue trackers

  • Social media posts

Vulnerabilities tracked in the private vulnerability repository have a source of ‘INTERNAL’. Like all vulnerabilities in the system, a unique VulnID is required to help uniquely identify each one. It’s recommended that organizations follow patterns to help identify the source. For example, vulnerabilities in the NVD all start with ‘CVE-‘. Likewise an organization tracking their own may opt to use something like ‘ACME-‘ or ‘INT-‘ or use multiple qualifiers depending on the type of vulnerability. The only requirement is that the VulnID is unique to the INTERNAL source.

Web App

Team Reviewer provides a unified interface for accessing all our tools, part of Security Reviewer Suite:

• Static Reviewer

• Dynamic Reviewer

• SCA Reviewer (Software Composition Analysis)

• Mobile Reviewer

Team Reviewer provides Scalability through NGINX/UWSGI and Django as native application.

See Team Reviewer’s Integration Checklist.

Enhanced Features

Open

Team Reviewer is 100% Web GUI app, based on OWASP Defect Dojo with a lot of enhancements:

• Multi-language Kit is available for localization.

• Direct execution of all features provided by Security Reviewer Suite (SAST, DAST, SCA, Mobile, Firmware)

• Extended Workflow and Reporting features, GDPR Compliance Level included

• Performant database, based on MariaDB 10.x Galera cluster. It can be changed to Oracle RAC 12 or any other Supported Relational Database

• Secured Source code and Operation platform, due to an accurate Static Code Review and Dynamic Analysis made by Security Reviewer and Dynamic Reviewer tools

• Encryption of DB Tables containing sensitive data (Users, Groups, Applications, Workflow, Policies, etc.)

• Enhanced support for third-party SAST, SCA, IAST, DAST and Network Scans tools.

• Mobile Behavioral Analysis integration (Mobile Reviewer)

• Software Composition Analysis (SCA) integration

• Software Resilience Analysis (SRA) Integration

• Azure Active Directory Single Sign On

• SQALE, OWASP Top Ten 2021, Mobile Top Ten 2016/2024, CWE, CVE, WASC, CVSSv2, CVSSv3.1, CVSSv4 and PCI-DSS 4.0.1/3.2.1 Compliance

• Native Application security Posture Mangement (ASPM)

Open

Triage

For Triaging, once you open the Findings:

Open

Bulk Edit 

You can choose the Analysis Type (for example: Security) using the Analysis combo box:

Open

You can select the finding(s) you want to triage one-by-one, or in bulk mode by collapsing per vulnerability group (usually Rule Desc or other criteria in the Group by combo box) using the Collapse all button:

Open

You can select and entire vulnerability gruoup, or, by clicking on the > selector on the Sev column, you can re-open only the vulnerability group you want to triage first:

Open

Then select one or more issue(s) using CTRL or SHIFT:

Open

The Edit Findings button will appear. Press it:

Open

Always write a Note (a text explaining why you're marking FP or AR the issue(s)) and choose between FP (False Positive aka Not An Issue) or AR (Accepted Risk). This Note will be stored together your Username, and in case anybody else add other notes or update this one, his/her Username will be also stored.

You can always turn back to non-FP/AR by clicking on Confirmed/Active or re-select/deselect the marked issue(s) using the table Rule/File/Line/Curr.Status/Note in the low part of the windows. Press Save button.

The issue(s) you marked as FP or AR will be suppressed from the current Results and will be considered as suppressed on all the next Engagements/Versions scans of the same Product/Application.

To complete the Triage, you can also assign the vulnerabilities issue(s) to someone else using JIRA, if you authorized.

Re-Scan

Following your first scan, as you fix issues you can scan the same Product/Application again multiple times.

This executes either a completely new scan on your current source code, or an Incremental Analysis.

Incremental Analysis functionality allow to perform a quick analysis taking in consideration only the files added or changed in the source code, compared to a previous other Engagement/Version.

When scanning the same Product/Application with a new Engagement/Version, doesn’t matter if full or incremental scan, the new scan automatically inherits all settings from the previous ones, Analysis/Language/Framework Options, False Positives, Accepted Risks and Exclusions included.

The Findings Summary Bar resumes the status of the findings based on the current view. It shows the total number of Findings, their number divided by Severity and the numbers of False Positives, Accepted Risks and the Solved and Reopened issues compared to the previous analysis. Clicking on the boxes, you can filter the data in the Findings list to see the the findings related to that box only

Open

You can still manually import a Custom False Positive/Accepted Risk or Exclusion List from a different Engagement/Version than the previous one.

Reports

Team Reviewer stores reports generated with:

• Static Reviewer Desktop

• Static Reviewer CI/CD plugins for Jenkins and GitLab

• SCA Reviewer Destkop

• SCA Reviewer CI/CD plugins for Jenkins and GitLab

• Dynamic Reviewer

• Mobile Reviewer

Open

Further, you can create your own custom reports by using Team Reviewer Report Generator.

Team Reviewer custom reports can be generated in Word, Excel and PDF. If you need different formats, open the Word reports and choose Save As…

Open

Custom reports allow you to select specific ISO 9001 cover to the report. These include:

Open

Notifications

Team Reviewer can inform you of different events in a variety of ways. You can be notified about things like an upcoming engagement, when someone mentions you in a comment, a scheduled report has finished generating, and more.

The following notification methods currently exist: - Email - Slack - HipChat - WebHook or Alerts within Team Reviewer

Open

You can set these notifications on a system scope (if you have administrator rights) or on a personal scope. For instance, an administrator might want notifications of all upcoming engagements sent to a certain Slack channel, whereas an individual user wants email notifications to be sent to the user’s specified email address when a report has finished generating.

In order to identify and notify you about things like upcoming engagements, Team Reviewer runs scheduled tasks for this purpose. 

Attached Documents

Products, Engagements and Tests permit to attach one or more documents, like Requirements docs, Project Docs, Evidences, Certifications, Risk Acceptances and any correlated docs you need.

It accepts PDF, Word, Excel and Images file formats.

Security Reviewer’s Security, Deadcode-Best Practices, Resilience and SQALE reports are uploaded as Engagement’s Attached Documents to Team Reviewer using REST APIs.

Results Correlation

Team Reviewer can import and correlate results from the following tools:

Team Reviewer can export correlated results to the following tools:

• SonarQube

• Fortify SSC

• ServiceNow

• Ox Security ASPM

• Invicti ASPM (formerly Kondukto)

See our EcoSystemPreview.

Authentication via LDAP/AD

LDAP (Lightweight Directory Access Protocol) is an Internet protocol that web applications can use to look up information about those users and groups from the LDAP server. You can connect the Team Reviewer to an LDAP directory for authentication, user and group management. Connecting to an LDAP directory server is useful if user groups are stored in a corporate directory. Synchronization with LDAP allows the automatic creation, update and deletion of users and groups in Team Reviewer according to any changes being made in the LDAP directory.

Architecture

Team Reviewer inherits the Architecture from DefectDojo.

Open

NGINX

The webserver NGINX delivers all static content, e.g. images, JavaScript files or CSS files. Because its roots are in performance optimization under scale, NGINX often outperforms other popular web servers in benchmark tests, especially in situations with static content and/or high concurrent requests.

uWSGI

uWSGI is the application server that runs the Dynamic Reviewer application, written in Python/Django, to serve all dynamic content.

Message Broker

The application server sends tasks to the Message Broker for asynchronous execution. RabbitMQ is our choice, an intermediary for messaging. It gives our applications a common platform to send and receive messages, and our messages a safe place to live until received.

Celery Worker

Tasks like deduplication or the JIRA synchronization are performed asynchronously in the background by the Celery Worker.

Celery Beat

In order to identify and notify users about things like upcoming Engagements, Team Reviewer runs scheduled tasks. These tasks are scheduled and run using Celery Beat. We have to ensure only a single scheduler is running for a schedule at a time, otherwise we’d end up with duplicate tasks. Using a centralized approach means the schedule doesn’t have to be synchronized, and the service can operate without using locks.

Initializer

The Initializer gets started during startup of Team Reviewer to initialize the database and run database migrations after upgrades of Team Reviewer. It shuts itself down after all tasks are performed. Migrations are Django’s way of propagating changes made to our models (adding a field, deleting a model, etc.) into our database schema. They’re designed to be mostly automatic. We should think of migrations as a version control system for our database schema. Initializer-makemigrations task is responsible for packaging up our model changes into individual migration files - analogous to commits - and Initializer-migrate task is responsible for applying those to our database.

 The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. We are making them once on your development machine and then running the same migrations on our colleagues’ machines, our staging machines, and our production machines.

Database

The Database stores all data of Team Reviewer. Currently MySQL is used.  Postgres, Oracle RAC and MariaDB are also supported. Results are also maintained in the filesystem as XML, for facilitating the Upgrades. For Core Data Classes, Team Reviewer uses the OWASP DefectDojo Models, as described in the related section below. For large numbers of analyses per year, it is recommended to use a dedicated database server and not the preconfigured MySQL database. This will improve the performances.

Models

Team Reviewer attempts to simplify how users interact with the system by minimizing the number of objects it defines.

Open

Product Type

Product type represent the top-level model. These can be business unit divisions, different offices or locations, development teams, or any other logical way of distinguishing different types of “organization”.

Examples:

·        Dev Team / Test Team / Sec Team / Ops Team

·        Internal / 3rd Party

·        Main company / Acquisition

·        San Francisco / New York offices

Product

This is the name of any Application, project, program, or product that you are currently testing.

Examples:

·        MyApplication

·        Internal wiki

·        Slack

Open

Engagement

Engagements are moments in time when testing is taking place. They are associated with a name for easy reference, a time line, a lead (the user account of the main person conducting the testing), a test strategy, and a status. Engagement consists of two types: Interactive and CI/C D. An interactive engagement is typically an engagement conducted by an engineer, where findings are usually uploaded by the engineer. A CI/CD engagement, as its name suggests, is for automated integration with a CI/CD pipeline.

Examples:

·        Beta

·        Quarterly PCI Scan

·        Release Version X

Open

Engagement consists of two types: Interactive and CI/CD.

An interactive engagement is typically an engagement conducted by an engineer, where findings are usually uploaded by the engineer.

A CI/CD engagement, as it’s name suggests, is for automated integration with a CI/CD pipeline

Each Engagement can include several Tests.

Test

Tests are the analysis performed by engineers to attempt to discover flaws in a product. Tests are bundled within engagements, have a start and end date and are defined by a test type.

Examples:

·        Static Reviewer Scan from Oct. 29, 2015 to Oct. 29, 2015

·        Nessus Scan from Oct. 31, 2015 to Oct. 31, 2015

·        API Test from Oct. 15, 2015 to Oct. 20, 2015

Finding

A finding represents a flaw discovered while testing, a vulnerability. It can be categorized with severities of Critical, High, Medium, Low, and Informational (Info).

Examples:

·        OpenSSL ‘ChangeCipherSpec’ MiTM Potential Vulnerability

·        Web Application Potentially Vulnerable to Clickjacking

·        Web Browser XSS Protection Not Enabled

A finding represents a flaw discovered while testing. It can be categorized with severities of Critical, High, Medium, Low, and Informational (Info).

Open

Each Finding get a Unique ID and a Status.

Findings are the defects or interesting things that you want to keep track of when testing a Product during a Test/Engagement. Here, you can lay out the details of what went wrong, where you found it, what the impact is, and your proposed steps for mitigation.

You can Force, if authorized, the Status, Severity, Risk Level. This operation will be tracked in a special log and can be viewed by authorized users.

You can Filter by: ID, Application, Severity, Finding Name, Date range, SLA, Auditor (Reporter, Found By), Status, Risk Level, N. of Vulnerabilities.

You can also Reference CWEs, or add links to your own references. (External Documentation Links included).

Templating findings allows you to create a version of a finding descriptor that you can then re-use over and over again, on any Engagement.

Endpoint

Endpoints represent testable systems defined by their IP address or Fully Qualified Domain Name.

Examples:

·        https://www.example.com

·        https://www.example.com:8080/products

·        192.168.0.36

REST API

Team Reviewer is built using a thin server architecture and an API-first design. API’s are simply at the heart of the platform. Every API is fully documented via Swagger 2.0.

The Swagger UI Console can be used to visualize and explore the wide range of possibilities:

Open

Prior to using the REST APIs, an API Key must be generated. By default, creating a Group (Team) will also create a corresponding API key. A Group (Team) may have multiple keys.

Team Reviewer’API API is created using Django Rest Framework. The documentation of each endpoint is available within each Team Reviewer installation at /api/v2/doc/ and can be accessed by choosing the API v2 Docs link on the user drop down menu in the header.

Each of main Swagger element provides different APIs for:

api-token-auth

The API uses header authentication with API key. To interact with the documentation, a valid Authorization header value is needed. If authorized, a user can also create a new API Authorization token.

admin-users

Open

This API requires an admin-level token to run, and HTTPS connection. It handles users, in term of:

• Users List

• User Creation. Create Users with first Password and associate Users to at least one Group (Team). Groups must be created with Users Partial Update request. User create, delete, modify or suspend

• Group (Team) create, modify or delete

• Groups assign to Users, with quick User remove

• User Update

• Users Partial Update. It has plenty of parameters to modify the following user’s Attributes:

Attributes

• Password settings (policy, expiration, change password)

• Enabling/Disabling Users or Groups feature-by-feature

• Enabling/Disabling Users or Groups to Audit analysis, Per Product, Per Component or Per Scan

• Enabling/Disabling Users or Group to assign vulnerability remediations to other Users or Groups, Per Product, Per Component, Per Vulnerability (Finding) Category, Per Single Vulnerability (Finding) or Per Scan

• Enabling/Disabling Users or Groups to Manage/Monitor Remediation plans Per Product, Per Component, Per Vulnerability (Finding) Category, Per Single Vulnerability (Finding) or Per Scan

• Enabling/Disabling Users or Groups to Manage Custom Rules

• Enabling/Disabling Users or Groups to create/modify/delete Vulnerability (Finding) Exclusions, Notes and False Positives

• Enabling/Disabling Users or Groups to create, modify or delete Components

• Adding/Remove Users to/from Admin role, for setting above permissions

• Enabling/Disabling Notification for a user/group using Slack, HipChat, Mail, WebHooks or Team Reviewer Alerts for: Product/Engagement/Test/Results/Report added, Jira Update, Upcoming engagement, User mentioned, Code Review involvement, Component Review requested. Notification other than the above can be achieved by WebHooks.

Multiple Users Partial Updates can be done to set more Attributes.

endpoints

To be used for DAST and IAST.

Open

Currently the following endpoints are available:

• Engagements (Start, Suspend, Delete and Close an Audit)

Open

• Findings (Vulnerability Management APIs)

Open

• Products (Application Groups)

Open

• Scan Settings

• Scans

Open

• Tests/ Reports

Open

• Further, a bunch of additional APIs are available, like: Development Environments, Tools/Plugin Configuration, Jira Configurations, Metadata, Systems Settings, Technologies, Views

• Last, there is a Command API for: System Status, Start/Restart/Stop/Suspend scan tasks, Execute Queries. This API requires an admin-level token.

Custom RuleSet

You can create your Custom RuleSet by enabling or disabling the existing Rules:

Open

You can:

• Choose the Application type: for example Mobile

• Choose the Analysis type: Security, Deadcode, Resilience, ISO 5055, Cloud-Ready, Green Software

• Choose the Language, Severity or Rule Set. Click on Filter when you’ve chosen

• Enable / Disable existing Rules and create your own Custom Rule Set, by clicking Save As button

• Export Rules to a CSV File. It will be located on Settings folder

• Press Save if you want to make this Custom Rule Set as default

• In RuleSet combo box, choose Custom if you want to modify a Custom Rule Set, you previously saved with Save As button

• Restore the default Rule Set by clicking on Restore button

Admin Kit

The Security Reviewer Admin Kit allows to add Custom Rules to be executed during the Static Analysis (Security or Dead Code - Best Practices) as well as to change some aspects of Static Analysis Reports. 

This can be done in three steps:

• Limit access to a single or a group of Static Reviewer features

• Change Rules priority (Severity)

• Add suggestions to reduce recurring False Positives by Evidence

• Add a new Rule to the Static Reviewer’s Rules XML File 

• Add a Report File for replacing an existing one.

We decide to give a limited access to our Admin Kit, reserved to Certified Users. A typical User can only select group of existing rules to be applied in a specific analysis, or to all analyses.

A Certified User, once purchased the Admin Kit, will receive a 1-day training by us, concerning how to design a Custom Rule properly.

Personnel using this Admin Kit should have the following Professional Profile:

• At least 3 year of experience on using Security Reviewer as Auditor. At least 100 Audits per year are required

• At least 5 years of experience in Secure Coding with Microsoft®NET

• In-depth knowledge of OWASP and CWE Compliance standards, and CVSS Risk methodology, all applied to at least 5 programming languages

• At least 5 years of experience in executing Static Analyses compliant with OWASP Top Ten 2013 or 2021, Common Weakness Enumeration (CWE) 4.9 or newer, Web Application Security Consortium (WASC) and PCI-DSS 4.0.1 or newer

• Developing at least 3 projects for each of 5 different programming languages, during the last 5 years

• “Security Reviewer Certified Professional – Master Rule Programming” Certified

You can Enable/Disable and change Severity of existing Vulnerability Detection Rules (authorized users only):

Open

You can create your Custom Rules (authorized users only):

Open

Once you created your own Rules, you must submit them all to us, using the Send button.

You can decide either to share your Custom Rules with the Community, or to reserve those Custom Rules to your company only.

You can declare Recurring False Positives by Evidence (authorized users only):

Open

DevOps CI/CD Integration 

See: SDLC IntegrationPreview

TOOL INTEROPERABILITY STANDARDS

Team Reviewer supports the following Tool Interoperability Standards:

• FPF

• SCARF

• SARIF

• CEF, LEEF and SysLog

• https://megalinter.io/latest/json-schemas/descriptor.html

FPF

Team Reviewer has a native format that can be used to share findings with other systems. The findings contain identical information as presented while auditing, but also include information about the project and the system that created the file. The file type is called Finding Packaging Format (FPF).

FPF’s are json files and have the following sections:

SCARF

We adopted a unified tool output reporting format, called the SWAMP Common Assessment Results Format (SCARF). This format makes it much easier for a tool results viewer to display the output from a given tool. As a result, we have fostered interoperability
among commercial and open source tools. The SCARF framework includes open source libraries in a variety of languages to produce SCARF and process SCARF. In addition, we have produced open source result parsers that translate the output of all the SCARF-based tools to SCARF. We continue to work towards tool interoperability standards by joining the Static Analysis Results Interchange Format (SARIF) Technical Committee. As a participating member, we contribute to creating a standardized, open source static analysis tool format to be adopted by all static analysis tool developers.

You can use SCARF Framework yourself using the libraries:

SARIF

We are also compliant to OASIS SARIF (Static Analysis Results Interchange Format). Some SDK are available:

• .NET SARIF SDK

• Python APIs and Lycan