We welcome all types of support cases! Bugs, Features, Enhancements, Questions, Ideas Cases provide an audit trail, tracking mechanism and assessment across entire customer base Not sure if it’s case worthy? Ask your CSM/Services/PM but don’t hesitate to submit a case of type “Question” Have multiple issues to report? Break them down into multiple cases if possible Issue is too complex / too broad / not reproduceable? We still want to hear about it and can often tell you if others are impacted Prioritize in context of other issues submitted by your organization Customers usually know best which issues are most critical for their organization but Revenera may not always have this knowledge. It removes a lot of ambiguity when customers help us with prioritization. Remember, you can view all suppport cases filed by your organization by using the 'All Cases' filter. We will take care of prioritizing your case in context of our entire customer base and strategic initiatives. Remember Priority = Urgency + Business Impact These are not pre-defined case fields, but this is critical information for our PMs. Urgency is all about time. Help us identify issues that may not be blockers today but you expect them to turn into blockers in a week, a month, a year. Advise us of any known deadlines this bug will affect. Business Impact is the effect of the issue on your business Here are some examples of business impact to consider: Business activity is affected Potential operational loss Potential financial loss Reputation shattering Inability or length of time to recover Don't forget to update the case if circumstances change Perhaps you found an acceptable workaround or moved to a different release alltogether. Please don't forget to update us on the changes so that we can better apply our valuable time and resources. ... View more

Based on popular demand, here is a curated list of all Code Insight resources for you to bookmark and subscribe to. Enjoy!  REVENERA CUSTOMER COMMUNITY Revenera Community – if you are reading this message, you're already here! Log in to access customer-only content like news, recordings, knowledgebase and forums/discussions, etc. Support Case Portal - file support cases and view open cases (login required; hint! use the ‘all cases’ filter to view support cases filed by others in your organization). Learning Center - educational videos on administering and using Code Insight (login required; click on ‘Code Insight’ tile, then register for a course) Product and License Center - download the latest releases, patches, plugins, release notes and documentation (login required) RELEASE SCHEDULES Code Insight Product Release Schedule – release schedule with up-to-date information on dates and payload (recommend to subscribe to this page). Electronic Update Data Release Notes – release notes for Electronic Update data - these updates contain new component/version/license/vuln data as well as special detection rules. (recommend to subscribe to this page) DOCUMENTATION Code Insight Documentation – select your Code Insight version of interest in the drop-down list to access: Product Release Notes Installation and Configuration Guide User Guide Plugins Documentation REST API Documentation ADD-ON REPORTS, TOOLS and EXAMPLES Code Insight GitHub Repositories – various reports and tools available for use with Code Insight that can be registered as-is or customized to suit your needs YOUTUBE Revenera’s YouTube Chanel – publicly accessible videos on Open Source, Code Insight, Cybersecurity and other Software Composition Analysis (SCA) topics LEGAL AND SECURITY TOPICS Code Insight Lifecycle and End of Life (EOL) Policy – answers questions about how long each version of Code Insight will be supported Revenera’s Application Security Incident Response Process Overview – describes our security policy, classification and response procedures Security Notifications Instructions – provides instructions for reporting security vulnerabilities against Code Insight ... View more

At the end of your evaluation or subscription term, Revenera will provide you with a new codeinsight.key file that will update the expiration date on your instance to allow you to continue using the system. Follow these instructions to replace to replace the key file. Steps Shut down Tomcat using the shutdown.sh script (shutdown.bat on Windows) Replace the existing codeinsight.key file in the Code Insight installation directory with the new codeinsight.key file Open the core.db.properties file in a text editor. This file is available in <Code Insight Installation Dir>/config/core/core.db.properties Replace the encrypted value in the 'db.password=' entry with the plaintext password for your database Save and close the core.db.properties file Start Tomcat using the startup.sh script (startup.bat on Windows) Note: In a multi scan server environment, these steps should be performed on the core server as well as each additional scan server ... View more

Code Insight Reports Code Insight offers standard reports that are packaged with the release contents, as well as a number of other useful reports available for download from our GitHub SCA report repositories. With our flexible Custom Reports Framework, these reports can easily be modified to report only on information most critical to you or you can create your own custom report from scratch. Listing of Available Reports The following is a list of reports currently available for use with Code Insight. This list will be updated as additional reports become available. Standard Reports (part of application codebase) Project Report Audit Report Notices Report Other Available Reports (source code available via GitHub) Project Vulnerabilities Report Project Compliance Report Project Comparison Report Project Inventory Report with Hierarchy SBOM Report (SPDX) SBOM Report (CycloneDX) SBOM Report (HTML & Excel) Claimed Files Report Third-Party Evidence Report Third-Party Notices Report (with optional inventory item notices text updates) Standard Reports Project Report The Project Report provides a summary and comprehensive view into a given project. This is one of our most popular reports - executives appreciate it for its high-level summary and operational risk assessment; development teams use it for archiving, backup and comparison of projects; legal uses it for a quick view of file-level copyrights and license information. The Project Report shows all project inventory organized by inventory priority, security vulnerabilities organized by severity, remaining scan evidence, and review and remediation tasks for the project. In addition, it provides an operational risk index to indicate overall project risk and lists all scanned files and their respective scan evidence. It also benchmarks the project against other known OSS projects that we see in the business. The report is available in JSON and Excel format. The calculations for operational risk index can be customized to suit the needs of your organization. The Excel version of the report includes the following tabs: Project Report: Summary Tab Project Report: Benchmarks Tab Things to Note About the Project Report The metrics and statistics in this report are based on the results of the most recent server scan and remote scan(s) associated with the project. Currently, Code Insight is able to report license evidence found in remote files scanned by a scan agent. This evidence is reflected (along with evidence detected by the Scan Server) in the charts and data in the following locations: Additional Evidence section of the Summary sheet Files with License sheet (with an Alias column to help you determine which files are remote) All Scanned Files sheet When the report lists codebase files, an alias and file path can be included with each file name in the format <alias>:<filePath> (or as separate properties). The alias is a unique descriptive name representing the scan-root path for the Scan Server or remote scan agent, and the file path is relative to scan root. (The actual absolute scan-root path for each scanner associated with the project is available on the project’s Summary sheet.) • The security vulnerability information in the report is based on the CVSS version (v3.x or v2.0) currently used by your Code Insight system for reporting purposes. If CVSS 3.x is used, vulnerability counts and information in the report are based on data from all CVSS v3 systems supported by Code Insight, currently v3.1 and v3.0. (A given vulnerability can have only one v3 score—either a v3.1 or v3.0 score, not both.) Audit Report The Audit Report provides another way to distribute your research and findings to others in your organization. Only published inventory items appear in the Audit reports so that items that are ready to be shared with the broader team can be presented in a clean manner while analysts continue their reviews on in-progress items. Audit Report: Summary View Things to Note about the Audit Report The metrics and statistics in this report are based on the results of the most recent server scan and remote scan(s) associated with the project. When the report lists codebase files, an alias and file path can be included with each file name in the format <alias>:<filePath>. The alias is a unique, descriptive name representing the scan-root path for the Scan Server or remote scan agent, and the file path is relative to scan root. (The actual scan root for each scanner associated with a project is available on the project’s Summary sheet.) The total lines of code listed on the Summary sheet is based on the server-side codebase only; the total does not include lines of code in the remote codebase(s). The security vulnerability information in the report is based on the CVSS version (v3.x or v2.0) currently used by your Code Insight system for reporting purposes. If CVSS 3.x is used, vulnerability counts and information in the report are based on data from all CVSS v3 systems supported by Code Insight, currently v3.1 and v3.0. (A given vulnerability can have only one v3 score—either a v3.1 or v3.0 score, not both.) Notices Report Code Insight provides the ability to produce a Notices report to satisfy the attribution requirements of most open source licenses. The report is created in text format. After Engineering has completed the remediation plan, resolving all rejected inventory items, the codebase is rescanned until it is approved for release. When the codebase is approved for release, you need to generate a Notices report to accompany the software application. This report is a compilation of all the open source/third-party components contained in the product and their license content (notices). The Notices report shows only published inventory. The inventory can be system-generated or custom and of any type—Work in Progress, Component, or License. The following items can appear in the Notices report for each inventory item: Inventory name—The entry in this field is based on naming conventions, which is usually the component name, version, and governing license name. Inventory URL—If the inventory URL is not available, Code Insight uses the associated component URL. If both are unavailable, no URL will appear in the report. Inventory Notices Text— The final “notices” text associated with the inventory item. It is pulled from the Notices Text field on the Notices Text tab for a selected inventory item in the Analysis Workbench or in Project Inventory. If this field is empty, Code Insight uses the content in the As-Found License Text field (also on the Notices Text tab), which shows the verbatim text license text found in the codebase by the system. If no As-Found License Text or Notices Text information is available, the text pulled from the Code Insight data library for the selected license is used in the Notices report. For more information, see Finalizing the Notices Text for the Notices Report Notices Report View Other Available Reports In Code Insight 2020 R1, we released a Custom Reports Framework which enables anyone with coding skills to create custom reports for Code Insight and register them for direct access in the product. The framework provides flexibility not only for our customers, but also for the Revenera team in order to bring you reports outside of our regular release schedule. Here are a few of our most popular reports: Project Vulnerabilities Report This is a security-focused report that calls out all vulnerable project inventory and lists of associated vulnerabilities. Use this report to quickly review security issues or to share data with your Security team. The report supports search and click-through to the vulnerable inventory in Code Insight for additional review. Vulnerabilities Report: Summary View Project Compliance Report This report lets you visualize inventory items for a project along with their current compliance issues. Compliance issues listed in this report are P1 licenses, rejected inventory items, unreviewed items, the presence of security vulnerabilities and outdated (old) versions but the report can be modified to report on compliance issues of interest to your organization. For example, if you are not working with products that are shipped and want to create a security-centric report, this is possible with a few modifications to the report code.   Project Comparison Report This report compares the inventory between two projects (e.g. two different products or two releases of the same product). Project Inventory Report with Hierarchy If you have designated a parent/child hierarchy for your projects in order to better represent your company offerings, the Project Inventory Report can be used to easily report across multiple projects. Running the report for the parent project will pull in all child projects. This is useful for keeping track of your software bill of materials (SBOM) and can be further customized to report on other inventory attributes, such as third-party notices to generate notices across projects. Compliance Report: Summary View Project SBOM Report (SPDX) This report produces a project Software Bill of Materials (SBOM) report in SPDX v2.2 format (.spdx). Project SBOM Report (CycloneDX) This report produces a project Software Bill of Materials (SBOM) report in CycloneDX v1.4 format (.xml). Project SBOM Report (Human Readable) This report produces a project Software Bill of Materials (SBOM) report in a human-readable format (HTML and Excel). Claimed Files Report This report allows users to show files they can claim based on evidence. It created a new inventory item and adds all files matching the provided criteria to this inventory items. The user can then ignore these files during manual analysis. Third-Party Evidence Report This report produces a table of evidence found during the last project scan. Third-Party Notices Report This is a new version of the standard third-party notices report. This report uses data from inventory items' third-party notices text field to generate a third-party notices report to satisfy the attribution requirement of open source licenses. This report will also optionally fetch licenses text associated with the component version for a given inventory item (where available) and update the third-party notices text field with this value.  HTML Report Functionality The majority of Code Insight reports are available in HTML format and can be loaded directly in the browser with the following functionality: The columns in the report can be sorted by clicking on the column header A search box is available for quickly locating specific parts of the report. The search is performed across all columns in the report. You can use the page numbers at the bottom to jump to a specific location Reports link back to the project(s) where the report originated to show you a live view of your inventory and evidence ... View more

Introduction In addition to standard license evidence and license details presented by Code Insight, users who require advanced license analysis can use the Research Pane to view additional license information from the compliance library such as license obligations and compatibility data or use the Inventory License view to see a side-by-side comparison of different licenses. Viewing and Editing a License To view or edit a license, do the following: 1. Click Research in the Main menu bar. 2. Enter a license name in the Search field, and click the Magnifying Glass. 3. In the search results, click the Plus icon next to the license you want to view or edit. 4. Click Edit. The Edit License page appears: 5. Click the appropriate tab to view and edit license information: • General Information: Name, URL, Description, Text. The Category field, for example, can be set so that you skip legal review. You can also choose to alter the workflow routing if you decide you wish to skip review levels The Family pull-down allows you to indicate if a license is in a family. The Select Family pull-down menu allows you associate the license with a family and choose what characteristics the license will inherit. Policy field contains relevant policy information. • License Analysis: This is not editable. Instead you can view the ranking of risk level, license requirements, and descriptions associated with the selected license. • License Metadata: The license metadata field definitions and value assignments are supported via API and external scripts. The assigned license metadata value fields are visible and can be searched against in the Web UI. see “Metadata Framework” for more information related to the metadata process and supported entities and datatypes. • License compatibility: On the Metadata tab, at the top, analyses of different license compatibility are provided. These analyses allow you to see which categories of compatibility a license may evoke. • License Obligations: This tab contains the set of license obligations associated with a given license. If a license belongs to the license family and does not have any license obligations, it will inherit the license obligations from the associated license family. License obligations can be defined in the Web UI by clicking on the Plus icon, or they can be bulk loaded by selecting Import from the Administration menu. Only an Application Administrator can bulk-import license obligations. The following graphic is an example of the information that appears on the Metadata tab: 6. When you finish viewing and editing the information, click Save. Inventory License Details When inventory is created in Code Insight to represent the software bill of materials (SBOM), users have the option to view additional license information for the detected license and compare it against similar licenses in the compliance library. Look for the license info icon   to access license text associated to the identified component or component-version, as-found license text, license comparison, license analysis (if available), license metadata (including compatibility analysis), license obligations, and license comments. Advanced license information appears in the following tabs: As-Found License Text Expected License Text License Family License Metadata License Analysis License Obligations License Compatibility License approval details are available for viewing by clicking on associated License icons. COMPONENT ICON DESCRIPTION Component Policy Flag icons   License always allowed.   License never allowed.   License has unknown policy since it depends on usage.   License does not have matching policy. License Text Comparison The License text comparison feature allows you to compare the following types of license text associated with a given inventory item: • License family • Expected license • As-found license To compare license types, do the following: 1. To view an inline comparison of two license texts associated with an inventory item, go to an inventory item. 2. Click the View License Details icon () next to the license name. The License Comparison page appears: 3. To compare two different license text types, select the two license text types to compare from the pull-down menus: • License Text: The license text for the selected license from the Code Insight Compliance Library. • As-Found License Text: The value of the As-Found License Text group field in Detector that was entered by the auditor. • License Family: The license text of the license family to which the selected license belongs. 4. Click the Compare button. NOTE: If a license text type is empty, it isn’t viewable. ... View more

Introduction Code Insight offers the ability for users to create custom vulnerabilities for known open source components that are part of the compliance library, as well as for other third-party components that are represented as custom components in the system. For example, users may want to add a custom vulnerability in order to represent a "zero day" vulnerability that does not yet have an assigned CVE or to add a vulnerability for a commercial component that was manually added to the system. Code Insight allows users to add, edit and delete custom vulnerabilities from Component Details or to use REST APIs to perform these functions. Custom vulnerabilities are also the backbone for the live NVD vulnerability detection that occurs during every scan based on a 4 hour sync with the NVD. When CodeAware identifies a new custom vulnerability that does not yet exist in the system or CodeAware identifies a vulnerability for a custom component-version, it automatically creates a custom vulnerability entry (and in the second case, also a custom component-version). If at a later time the vulnerability is picked up by Code Insight during Electronic Update, the custom vulnerability is automatically replaced with it's non-custom version. This process occurs automatically without user involvement. By remapping custom vulnerabilities and custom component-versions once they become available, Code Insight ensures that security vulnerability alerts are issued for future scans. Adding an Existing Vulnerability to a Component Version Use the following procedure to manually add an existing security vulnerability to a component version—that is, add a vulnerability already identified in the Code Insight data library but currently not associated with the component version. Once added, this vulnerability is considered a custom vulnerability for the component. To add an existing vulnerability to a component version, do the following: 1. Click Research on the Main menu bar. The Research page appears. 2. In the Search field, enter the name of the component for which you wish to add the vulnerability. 3. Click the magnifying glass icon. 4. Locate the desired component, and click the associated shield icon in the Vulnerabilities column. 5. Locate the component version to which you want to add a vulnerability, and click the shield icon in the Vulnerabilities column to open the Security Vulnerabilities dialog. 6. Click Associate Vulnerability to open the Associate Vulnerability dialog. 7. In the Search for Vulnerability Name field, enter the exact name of the existing vulnerability you want to add. 8. Click the magnifying glass icon. • If you have entered a vulnerability name that exists in the Code Insight data library, the vulnerability and its details are listed. (Click the plus icon to the left of the vulnerability to show the its description.) • If you entered a vulnerability name that does not exist in the Code Insight data library, no results are listed. Make sure you have entered the exact vulnerability name and try again. If you continue to see no results, you have the option to create a new vulnerability and associate it with the component version. For details, see the next section, Adding a New Vulnerability to a Component Version. 9. If the security vulnerability displayed is the desired vulnerability, select it and click Associate to add it to the component version. Adding a New Vulnerability to a Component Version Use the following procedure to manually add a new security vulnerability to the component version—that is, create a vulnerability that has not yet been identified in the Code Insight data library and associate it with the component version. Once the vulnerability is created and associated with the component version, it is added to the data library as a custom vulnerability available for association with other components. To add a new vulnerability to a component version, do the following: 1. Click Research on the Main menu bar. The Research page appears. 2. In the Search field, enter the name of the component for which you wish to add a new vulnerability. 3. Click the magnifying glass icon. 4. Locate the desired component, and click the associated shield icon in the Vulnerabilities column. 5. Locate the component version to which you want to add a vulnerability, and click the shield icon in the Vulnerabilities column to open the Security Vulnerabilities dialog. 6. Click Add New Vulnerability to open the New Vulnerability dialog. Enter the required vulnerability name and description, and select a severity from the Severity pull-down menu. The URL field is optional and can be left blank. 8. Click Save to save the new vulnerability and associate it with the selected component version. Disassociating a Custom Vulnerability from a Component Version This section describes how to disassociate a custom vulnerability from a component version. Note that a custom security vulnerability for a component version is one that was manually added to the version using a public REST or Java API or either of these procedures: Adding an Existing Vulnerability to a Component Version or Adding a New Vulnerability to a Component Version. To disassociate a custom vulnerability from a component version, do the following: 1. Click Research on the Main menu bar. The Research page appears. 2. In the Search box, enter the name of the component. 3. Click the magnifying glass icon. 4. Locate the desired component, and click the associated shield icon in the Vulnerabilities column. 5. Locate the component version that has the custom vulnerability that you want to disassociate, and click the shield icon in the Vulnerabilities column. 6. Click the red x icon next to the custom vulnerability that you want to disassociate from the component version. (Only custom vulnerabilities have the x icon.) 7. Click Yes to confirm the deletion.   ... View more

1. What is the Custom Detector Framework A generic framework within the Codeinsight that allows users to implement their own custom file content parsing logic and drop it into Code Insight for automatic creation of inventory to aid in building of the Software Bill of Materials (SBOM) Supports both standard (XML, JSON, YAML etc.) and non-standard manifest file types Enables automated discovery of components with license and vulnerability mappings Creates automated inventory for top-level and direct and transitive dependencies Processes the JSON rule configurations provided for each of the manifests 1.1 Users The Custom Detector Framework can be used by any of the following groups to extend current detection functionality of Code Insight based on their own set of requirements . Customers Code Insight Service/Support teams Code Insight Partners 1.2 Providing Custom Detector Rules to Code Insight The users of the framework will provide JSON rules configuration files at the specified location in the Update-Service update folder at  <Codeinsight_installed_folder>/config/.codeaware/updates For each of the manifest files, user must read the section “how to write manifest rules?” in order to create a new json rule configuration for that manifest. 1.3 Supported Manifest Type and Inventory Types XML manifest rules for top-level and first-level dependencies JSON manifest rules for top-level and first-level dependencies 2. How to Write Rules for XML Manifest Files This section covers rules needed to identify both top-level and first level dependencies from an XML manifest file. Definition of attributes used within the rule: package-indicator: This attribute holds the value for manifest file extension or indicator file. Example:  .csproj, .nuspec package-type: this attribute defines the what type of package-manager a manifest file belongs to. Example: C-Sharp package, Conda package format: the attribute holds the supported manifest format. Example: xml, json packageRules: this element will have list of the rules, which define for top-level and first-level dependencies. ruleType: this element holds either the values top-level or first-level packageName: this attribute holds the name of the package name attribute in the manifest file. Also, this value should be given starting from the hierarchy.  Example: "packageName":                 {                   "name": "Project.PropertyGroup.RootNamespace",                   "valueType": "XMLElement"                 } Note: In case of XML manifest, the element name should follow hierarchies starting from the root element. In the above example, the root element of the XML file referred is “Project” and name is derived as “Project.PropertyGroup.RootNamespace” version: this attribute holds the name of the version attribute in the manifest file. Example: "version": {   "name": "Project.PropertyGroup.ProductVersion",   "valueType": "XMLElement" } valueType:  this attribute holds either XMLElement or XMLAttribute.        license: this attribute is optional and holds the name of the license attribute in the manifest rule. Example: "license": {   "name": "Project.PropertyGroup.License",   "valueType": "XMLElement" } 2.1 XML File Example: CSharp Package Detection Using Custom Rules The following CSharp Package example demonstrates how a custom detector can be created to process the 'csproj' manifest file type to create automated inventory. Code Insight currently uses this custom detector to create automated inventory for CSharp. Users can further extend the rule to catch additional inventory if needed. 2.1.1 Sample CSharp Package Using a 'csproj' Using the XML Format <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">   <PropertyGroup>     <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>     <Platform Condition=" '$(Platform)' == '' ">x86</Platform>     <ProductVersion>8.0.30703</ProductVersion>     <SchemaVersion>2.0</SchemaVersion>     <ProjectGuid>{FDD11759-02FA-44BF-84C6-2F5B2AA5B6BC}</ProjectGuid>     <OutputType>Exe</OutputType>     <AppDesignerFolder>Properties</AppDesignerFolder>     <RootNamespace>Sample</RootNamespace>     <AssemblyName>Sample</AssemblyName>     <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>     <TargetFrameworkProfile>Client</TargetFrameworkProfile>     <FileAlignment>512</FileAlignment>   </PropertyGroup>    <ItemGroup>     <PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />     <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />     <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1"/>     <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.1" />   </ItemGroup> </Project> 2.1.2 Sample XML Manifest Rule for CSharp Package 'csproj' File The below rule identifies both the top-level and first level components. {   "package-indicator": ".csproj",   "package-type" :"cSharp package",   "format": "xml",    "packageRules": [        {          "ruleType": "top-level",          "packageName":               {                 "name": "Project.PropertyGroup.RootNamespace",                 "valueType": "XMLElement"               }          ,          "version":               {                 "name": "Project.PropertyGroup.ProductVersion",                 "valueType": "XMLElement"               }        },        {          "ruleType": "first-level",                "packageName":               {                 "name": "Project.ItemGroup.PackageReference.Include",                 "valueType": "XMLAttribute"               },               "version":               {                 "name": "Project.ItemGroup.PackageReference.Version",                 "valueType": "XMLAttribute"               }               },        {          "ruleType": "first-level",                "packageName":               {                 "name": "Project.ItemGroup.Reference.Include",                 "valueType": "XMLAttribute"               },               "version":               {                 "name": "Project.ItemGroup.Reference.Version",                 "valueType": "XMLAttribute"               }               }   ]  } 3. How to Write Rules for JSON Manifest Files This section covers the rules needed to identify both top-level components from a JSON manifest file. Definition of attributes used within the rule: package-indicator: This attribute holds the value for manifest file extension or indicator file. Example:  Conda package index.json package-type: this attribute defines the what type of package-manager a manifest file belongs to. Example: Conda package format: the attribute holds the supported manifest format. Example: xml, json packageRules: this element will have list of the rules, which define for both top-level and first-level dependencies. ruleType: this element holds either the values top-level or first-level. packageName: this attribute holds the name of the package name attribute in the manifest file. Also, this value should be given starting from the hierarchy.  Example: "packageName": {   "name": "name",   "valueType": "JSONElement" } In case of JSON manifest file type, the element name should follow hierarchies starting from the root element. In the above example, the root element of the file referred is “Project” and the name is derived as “Project.PropertyGroup.RootNamespace” version: this attribute holds the name of the version attribute in the manifest file. Example: "version": {   "name": "version",   "valueType": "JSONElement" } valueType:  this attribute holds either XMLElement or XMLAttribute.        license: this attribute is optional and holds the name of the license attribute in the manifest rule. Example: "license": {   "name": "license",   "valueType": "JSONElement" } packageDependency: this attribute is used only for first-level rules, to specify dependency details. Example: "packageDependency":         {           "name": "depends",           "valueType": "JSONStringArrayElement"         }             In the packageDependency attribute the valueType can be either of the below 2 types JSONStringArrayElement – This is used when the dependencies are represented as Arrays in JSON: Example: "depends": [         "terminado 0.3.3",         "tornado 4.1.0",         "traitlets 4.3.1"] JSONMapElement – This is used when the dependencies are represented as Map in JSON: Example:  “dependencies”: {        "terminado": "0.3.3",         "tornado": "4.1.0",        "traitlets": "4.3.1"} 3.1 JSON File Example: Conda Package Detection Using Custom Rules This section covers rules needed to identify both top-level and first level dependencies from a JSON manifest file. 3.1.2 Sample Conda Package 'index.json' File Which Follows JSON Format {   "app_cli_opts": [     {       "args": "--port %s",       "default": "8080",       "name": "port",       "summary": "Server port ..."     }   ],   "app_entry": "jupyter-notebook",   "app_type": "web",   "arch": "x86_64",   "build": "py27h3661c2b_2",   "build_number": 2,   "depends": [     "ipykernel",     "ipython_genutils",     "jinja2",     "jupyter_client",     "jupyter_core",     "nbconvert",     "nbformat",     "python >=2.7,<2.8.0a0",     "terminado >=0.3.3",     "tornado >=4",     "traitlets >=4.3"   ],   "icon": "df7feebede9861a203b480c119e38b49.png",   "license": "BSD 3-clause",   "name": "notebook",   "platform": "linux",   "subdir": "linux-64",   "summary": "Jupyter Notebook",   "timestamp": 1506020374312,   "type": "app",   "version": "5.0.0" } 3.1.3 Sample JSON Manifest Rule for Conda Package 'index.json' File  {   "package-indicator": "index.json",   "package-type" :"conda package",   "format": "json",    "packageRules": [        {          "ruleType": "top-level",          "packageName":               {                 "name": "name",                 "valueType": "JSONElement"               }          ,          "version":               {                 "name": "version",                 "valueType": "JSONElement"               },               "license":               {                 "name": "license",                 "valueType": "JSONElement"               }               },        {          "ruleType": "first-level",          "packageDependency":               {                 "name": "depends",                 "valueType": "JSONStringArrayElement"               }             }   ]  } 4. Version Resolution Support As an initial support for semantic version in custom-detector-framework, NuGet package manager is considered The support for semver will be added cumulatively by adding new package managers to the framework Please do note that the semantic version resolution is not completely generic The following rule structure must be added to support version resolution: "dependencyVersionResolution": { "type":"semver", "componentRegistryURL":https://api.nuget.org/v3-flatcontainer/#componentName/index.json "responseAttribute": "versions"    } Here, in the above structure: “dependencyVersionResolution”: This is the main element for the version resolution. “type”: This attribute is used to represent the type of version resolution. For semantic version resolution, the value will be “semver”. “componentRegistryURL”: Every package manager has its own registry URL. Also we can get the component info and its available versions from the registry.  This attribute expects a generic registry URL representation to get all the available versions for a component. In the above structure https://api.nuget.org/v3-flatcontainer/#componentName/index.json is the common registry URL for nuget packages to get all available versions of a component. Also please note the #componentName substitute parameter used. This parameter should be used for other package managers also. This parameter is basically a place-holder for component name. “responseAttribute”: This attribute expects the response attribute of componentRegistryURL which has all the available versions. For example, in the above structure “versions” attribute in the response of https://api.nuget.org/v3-flatcontainer/#componentName/index.json has all the available versions. The below is the complete rule for NuGet having semver support. {        "package-indicator": ".nuspec",        "package-type": "Nuspec package",        "format": "xml",        "dependencyVersionResolution": {               "type": "semver",               "componentRegistryURL": "https://api.nuget.org/v3-flatcontainer/#componentName/index.json",               "responseAttribute": "versions"        },        "packageRules": [               {                      "ruleType": "top-level",                      "packageName": {                            "name": "package.metadata.id",                            "valueType": "XMLElement"                      },                      "version": {                            "name": "package.metadata.version",                            "valueType": "XMLElement"                      }               },               {                      "ruleType": "first-level",                      "packageName": {                            "name": "package.metadata.dependencies.dependency.id",                            "valueType": "XMLAttribute"                      },                      "version": {                            "name": "package.metadata.dependencies.dependency.version",                            "valueType": "XMLAttribute"                      }               },               {                      "ruleType": "first-level",                      "packageName": {                            "name": "package.metadata.dependencies.group.dependency.id",                            "valueType": "XMLAttribute"                      },                      "version": {                            "name": "package.metadata.dependencies.group.dependency.version",                            "valueType": "XMLAttribute"                      }               }        ] }   Example of Nuget nuspec XML file is as follows, <?xml version="1.0"?> <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">   <metadata>     <id>NHibernate</id>     <version>4.1.2.4000</version>     <authors>NHibernate community, Hibernate community</authors>     <owners>NHibernate community, Hibernate community</owners>     <licenseUrl>https://raw.github.com/nhibernate/nhibernate-core/master/lgpl.txt</licenseUrl>     <projectUrl>http://nhibernate.info</projectUrl>     <iconUrl>https://raw.github.com/nhibernate/nhibernate-core/master/logo/NHibernate-NuGet.png</iconUrl>     <requireLicenseAcceptance>false</requireLicenseAcceptance>     <description>NHibernate is a mature, open source object-relational mapper for the .NET framework. It is actively developed, fully featured and used in thousands of successful projects.</description>     <summary>NHibernate is a mature, open source object-relational mapper for the .NET framework. It is actively developed, fully featured and used in thousands of successful projects.</summary>     <language>en-US</language>     <tags>ORM, DataBase, DAL, ObjectRelationalMapping</tags>     <dependencies>       <dependency id="Iesi.Collections" version="[3.2, 5.0)" />     </dependencies>   </metadata> </package> 5. Other The rule in packageRules must contain one top-level rule, otherwise the rules are not processed If there are no top-level components identified by the framework using rules, no inventories will be generated for those manifest files   ... View more