You can run OpenText Core SCA in any of the following ways:

• Web: The OpenText Core SCA web app enables a browser-based experience, providing all functions, including security and license scanning, automation, reporting, and more.

• CLI: The OpenText Core SCA Command Line Interface enhances open-source security and license compliance for your project through the command prompt. It allows you to conduct vulnerability scans on your local machine and seamlessly integrate OpenText Core SCA into your pipeline.

• API: allow you to integrate our service into your code, CI pipelines, and more.

• Browser: integrates the Select option directly into your browser, allowing you to examine an open-source project's health metrics and license information without leaving the page.

The support for this language is currently in beta. Vulnerability results may be less accurate than normal.

OpenText Core SCA now tracks Rust dependencies through Cargo, using its associated Cargo.lock files. This file is generated whenever one of the following commands is executed:

If the file is committed to the repository, it will be automatically scanned for dependencies when integrated with OpenText Core SCA CI/CD pipeline.

Supported file formats and features

OpenText Core SCA currently tracks PHP dependencies installed through Composer dependency manager, using either the composer.json or composer.lock files.

OpenText Core SCA recommends including the composer.lock file, as it contains resolved versions of both direct and indirect dependencies, leading to more accurate scan results.

The composer.lock file is generated whenever one of the following commands is executed:

If at least one of the supported files is committed to the repository, it will be automatically scanned for dependencies when integrated with OpenText Core SCA CI/CD pipeline.

When you sign up for a free account with OpenText Core SCA, you will receive 1,000 initial scan credits to use at your convenience, with no expiration date. After using your initial credits, you will receive an additional 100 free scan credits added to your account on the 1st of each month.

give you access to a range of premium features, including unlimited scans.

To upgrade your account, click Upgrade to premium in the left-side menu and follow the prompts. You must specify the number of developers who will be contributing to the repositories integrated with OpenText Core SCA. After you complete the process, you will have access to OpenText Core SCA service with unlimited scans. To upgrade to our with unlimited scans, .

For an enterprise subscription, contact our sales team at .

Assume there is a repository with huge number of vulnerabilities. It will take time to go through each one of them and potentially fix them. OpenText Core SCA offers the ability to open a pull request where it tries to solve many vulnerabilities at once.

Endpoints

/api/{version}/open/repository/{repositoryId}/pull-request/branch/{branchId}/{notify}/{includeUnaffected}

/api/{version}/open/repository/{repositoryId}/get-branches

OpenText Core SCA can generate a new bulk pull request for the repository, with ID 15707 in this case (shown in the URL). The branch ID is found using the get-branches endpoint.

For information about OpenText Core SCA security, refer to the following document.

OpenText Core SCA defines contributing developers as developers contributing to the repositories integrated with OpenText Core SCA.

In order to add more contributing developers to your subscription:

1. Go to Billing on the left side menu.

2. Click your subscription.

3. Click Edit subscription to add or remove seats.

You can use the OpenText Core SCA tool in English and Swedish.

To change the language in the tool:

1. Hover on your name at the bottom of the left-side menu.

2. Click User settings.

3. Select your preferred language in the Language drop-down. Selecting By browser sets the language according to your browser settings. The setting will be saved automatically.

Due to limitations, it is not always possible to identify the default branch except for GitLab users. For other users, the default branch can be identified if the branch name is either master or main. In cases where the default branch cannot be determined, the data from the branch that contains the most recent commit is displayed.

OpenText Core SCA helps you take full control of security, compliance, and project health with a toolkit that revolutionizes the way you use open source.

First Setup

Integrating with OpenText Core SCA

OpenText Core SCA's Tools

The OpenText Core SCA Fundamentals - webinar recording

Check out our latest training webinar to learn the fundamentals of OpenText Core SCA:

Need help getting started with OpenText Core SCA? Join one of our and ask questions directly to our experts.

Need more help?

If you have any additional questions feel free to contact. You can also join to stay up-to-date with everything related to OpenText Core SCA and the open source universe.

Follow these steps after creating an account with OpenText Core SCA:

1. Set up an integration If you have a project's dependency file but setting up an integration is not applicable at the moment, you can upload the dependency file manually.

2. Set up a license use case When you first access the license view, you will see that all repositories are marked as "Unknown" in the risk column. This is because you have not configured any use cases for your repositories yet. Defining a use case helps the tool understand how you organize the code in your repositories, which affects the risk associated with any particular license.

3. The automations engine allows for rules to be triggered based on conditions. For example, a rule can fail a pipeline if it detects a new high-risk vulnerability detected, or an unwanted license.

   By default, OpenText Core SCA has set up a number of rules to prevent unwanted licenses or dangerous vulnerabilities. Click the toggle button to disable any rule.

You can access our help center by clicking the Help button at the right bottom of the screen.

• Interactive tutorials explain the vulnerabilities and assist you in setting up integrations and license-related automations

• Access to our Docs enable you to find answers to your questions through the search bar

• Our Instant live chat is open weekdays from 9:00 to 17:00 CET and connects you with OpenText Core SCA experts ready to answer any of your questions

In case you want to get in contact with our support team through a different channel, you can also e-mail directly to . You can expect a reply within 1 business day.

Unable to access the help widget

To get access to live chat or the Help widget in the tool, onboarding tools, or service notices, you must accept the Support and Functional cookies. For more information about these cookies, see the .

For each alerted vulnerability, you can assign a status. You can choose to mark the vulnerability as unaffected, or vulnerable or you can choose to snooze or pause. All the vulnerabilities have a default status of unexamined until you decide to change it.

To set a review status:

1. Go to your Repositories from the left side menu.

2. Click a specific repository.

3. In the Repository view, click a specific CVE.

4. In the Actions section, choose one of the following available status choices:

• Unaffected: You can mark the CVE as Unaffected to ignore the vulnerability.

• Vulnerable: You can flag a CVE as Vulnerable to ensure it is on your radar.

• Pause rule triggering: You can wait to take action and pause automation triggering. You can either Snooze or Pause. When you snooze the CVE, you can define a period of time (1 week, 1 month and so on). When you pause the CVE, you can pause until a new fix is available. Pausing is only supported for the Github app.

Use automation to set a review status

The automation engine can help you remove manual work, by setting review statuses. You can use automations to flag CVEs as unaffected or vulnerable. For example, you can create a rule that when a dependency contains a vulnerability where CVSS is low (0.0-3.9), then mark the vulnerabilities as unaffected.

The first time you visit the License view; you willl notice that the value in the risk column is set to Unknown for all licenses. This is because you have not yet configured any use cases for your repositories. You can select a use case through the API using the endpoint:

/api/{version}/open/repository-settings/repositories/{repositoryId}/select-use-case

To do so, send a JSON containing a choice of the use case, for example:

"useCase": 2

Here, the useCase can be one of the following integers:

• 0/null - Unknown

• 1 - Non-distributed internal

• 2 - Non-distributed public

• 3 - Distributed generic

• 4 - Distributed electronics

Here’s an example showing you how to set the use case to “Non-distributed public” for a repository with ID = 1337:

Open Source Select enables you to view more details of the dependency to better determine their quality and state. After clicking on a specific project, you are able to learn more from the description, Readme (fetched from the project’s GitHub repository) and external links, and dive deep into the Health metrics to truly understand the strengths and weaknesses of the dependency.

Similar dependencies

To help you find new projects, we list two dependencies with similar functionality and their respective popularity and contributor scores. You can use the Compare functionality to compare them to the dependency you are currently viewing.

Health metrics

You can find a quick overview of the on top of the page, and a comprehensive view in the metric cards below. Each metric card visualizes their practices using multiple charts. You can hover on each practice's position in the chart to see the score of that practice, and if you click on one, all of its features are shown.

Choose open source components with OpenText Core SCA's open source select and start left - video guide

Root fixes contain the first next version of the direct dependency in the dependency tree that does not contain a vulnerable version of the affected dependency. In simpler terms, a Root fix is a solution to a dependency vulnerability that starts at the root of the dependency tree.

By addressing the root cause of the vulnerability, Root fixes ensure that the entire dependency tree is updated, using the version constraints set up by its dependencies. This way of updating dependencies is generally preferred over updating the vulnerable dependency directly, as it has a much lower risk of errors and breaking changes. It also eliminates the need for manually researching the required direct dependency update, saving developers valuable time.

Solve a vulnerability using root fix

1. Click Repositories in the left side menu and select your project. Here you can see a list with all the CVEs found.

2. Click one CVE to open the vulnerability page.

3. Go to the Introduced through section and select the dependency file to analyze. In some cases, the scan can find more than one dependency file within your project. You can see in green which is the closest secure version of the root package to update.

   If OpenText Core SCA is not able to find a secure version to solve the vulnerability, the Introduced through section shows an unknown.

Once the scanning is completed, the repository should no longer have this vulnerability.

Solve a vulnerability using root fix - video guide

Open Source Select provides you with information about projects that have been declared as no longer being maintained or about to reach end of life. Currently, we only provide this information for NPM packages.

The different states of a project are:

• Repository archived - Indicates that the repository is already archived.

• Package deprecated - Indicates that the package is officially deprecated.

• Vendor announced - Indicates that the vendor has announced an end-of-life date after which the package or project will no longer be maintained.

OpenText Core SCA now tracks Swift dependencies through CocoaPods using Podfile.lock files.

If the file is committed to the repository, it will be automatically scanned for dependencies when integrated with OpenText Core SCA CI/CD pipeline.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

For OpenText Core SCA to be able to generate Pull Requests on your behalf, you should do some configuration based on the platform:

• GitHub: To enable pull requests, you are required to integrate with GitHub using the GitHub app.

• GitLab: if you have set up an integration to GitLab, to enable merge requests, you should provide additional credentials (as explained in the article).

• Azure DevOps: if you have set up the , to enable pull requests, you must provide additional credentials (as explained in the article).

Is OpenText Core SCA’s service on prem or SaaS?

OpenText Core SCA is a Software as a Service (SaaS) solution currently.

Here are some of common security terms that are used within the tool:

Common Vulnerability Enumeration (CVE)

This is a vulnerability published in an open database by NVD, with an assigned vulnerability ID known as CVE ID. Examples include Heartbleed (CVE-2014-0160) and Shellshock (CVE-2014-6271).

OpenText Core SCA now supports tracking Scala dependencies through the following methods:

• SBT, by utilizing pom.xml files

• , to find dependencies not specified in manifest files

The popularity of a repository is another crucial indicator of the health of a project. It signifies interest from both developers and users alike, pointing towards viability and continued development. Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on the . You can find the data model illustrated below:

Usage

This practice describes the usage of a repository among open-source users. The following features of Usage are measured:

The Vulnerability Export summarizes data about all of your projects. It shows a summary of the total number of vulnerabilities found, their classification between critical and high, and their review status.

Group automation rules into policies to simplify the management of these rules by providing a single point of control. This makes it easier to enable, disable, or modify multiple rules at once. Additionally, Enterprise users are able to use those policies to evaluate packages in Open Source Select with .

View existing policies

1. Go to Automations on the left side menu (you can also access automations for a specific repository by clicking Automate on the top right corner). 2. See a list of your existing policies under the tab Policies. 3. Click a specific policy to see the full list of rules that are part of it. Here, you can add new rules, enable/disable/edit them, and remove them from the policy.

The Select Browser Extension allows you to view OpenText Core SCA's Health data directly on a repository or a package manager's GitHub page. The extension integrates seamlessly with your browsing experience, providing you with comprehensive insights into the project without navigating away from the site.

Edit

To edit an existing automation rule:

1. Go to Automations on the left side menu.

At OpenText Core SCA, we group licenses into different license families, applicable to different use cases. They are shown in one of the columns in the License view and can be used in your customized automation rules. Here’s how we categorize them:

Proprietary

A non-free license, or proprietary license, allows the owner to restrict the use, modification, and redistribution of the software.

OpenText Core SCA now tracks Objective-C dependencies through CocoaPods using Podfile.lock files. If this file is committed to the repository, it will be automatically scanned for dependencies when integrated with OpenText Core SCA CI/CD pipeline.

Supported file formats and features

Project health is an important aspect to consider when selecting dependencies. But what does Project Health even entail? OpenText Core SCA's Open-Source Health Metrics can help you gain an understanding of key aspects of any open-source project and make informed decisions when choosing what to bring into your codebase.

What is a health metric?

A Metric is a measurement of a key aspect of an open-source project’s overall quality. For example, its contributors or its popularity. Our underlying data model aggregates data points into sub-metrics, which are then aggregated into a metric. We call these:

You can use your automation policies to evaluate new packages in Open Source Select. If you are looking for a new package in Select, you can check whether or not it will trigger an automation rule using Start Left Policies.

enables you to compare projects side by side and gain insight into their individual strengths and weaknesses. You can compare aspects such as security, contributor commitment, and popularity.

To compare (up to three) projects:

1. Select the projects that you want to compare by clicking the Add to comparison (the scale icon) button on each project's card.

2. Click Compare selected dependencies below the search bar.

You can get in touch with our team through two channels:

• Our instant live chat: Our instant live chat is available on weekdays from 9:00 AM to 5:00 PM CET. Connect with our OpenText Core SCA experts, who are ready to answer any questions you may have. You can access the chat through the or by clicking the Chat button.

• Email: Send an email directly to . You can expect a reply from us within 1 business day.

In order to delete your user account:

1. Hover on your name at the bottom of the left-side menu.

By default, all users are able to snooze a vulnerability by changing its Review status. As the administrator, you are also able to disable that feature for all users in your company.

To manage the snoozing functionality for the company account:

1. Go to Admin tools on the left side menu.

2. Type your password to enter the administrative mode.

You can choose between two different billing periods, monthly and annual.

To change your billing frequency:

1. Go to Billing on the left side menu.

2. Click your subscription.

You can export the filtered and visible data in the table to a CSV file. The CSV file is sent to your registered email ID. The exported file reflects the current filtered view of the table, ensuring that only the visible data is included. To export the table data:

1. Click Export table located at the top-right corner of the table. The Export table pop-up window appears.
2. Click Export to export the data.

Two-factor authentication increases the security of your account by introducing a second authentication method.

To manage 2FA:

1. Hover on your name at the bottom of the left-side menu.

2. Click User settings.

3. Under Two Factor Authentication, select or deselect one or more options by ticking the corresponding checkboxes.

Email authentication

When this option is enabled, you will start receiving confirmation codes to your email upon login. From now on, every time you log in, you will be prompted to enter the code received in the emails.

Google authenticator

When this option is enabled, you will be required to approve your logins using the Google Authenticator app. To enable this option:

1. Tick the corresponding checkbox under Two Factor Authentication. This will prompt a modal with a QR code to appear on your screen.

2. Open the Google Authenticator app on your phone and scan the QR code. This will generate a single use code.

3. Enter the code in the Verification code field in the tool and click Verify. From now on, every time you log in, you will be asked to enter the authentication code from your Google Authenticator mobile app.

It is possible to add multiple credit/debit cards as payment methods. The first card you add is automatically set as the default payment method. Once another card is added, you will be able to select it as the default payment method instead.

If possible, the default card is charged first. If unable to charge the primary card, the secondary card will be used instead.

To add a new card:

1. Go to Billing on the left side menu.

2. Click Payment Methods.

3. Click Add New.

4. Select a method and enter the details.

You can easily access all the past invoices for your account. To do so:

1. Go to Billing on the left side menu.

2. Click Billing History to access past invoices for your account.

Apart from the various programming package management systems, OpenText Core SCA also supports package managers for various Linux distributions, allowing you to find and monitor potential vulnerabilities of your server or Docker container.

To start tracking your server or Docker vulnerabilities, you should first execute your package manager(s) list command and redirect the output to a text file:

• For Debian, Ubuntu and most derivatives, execute the following command:

apt list --installed > apt.list

• For Alpine Linux which is widely used by Docker containers, execute the following command:

apk list --installed > apk.list

To scan them for dependencies, the output file(s) should be either committed to the repository or manually uploaded.

OpenText Core SCA currently supports tracking Java or Kotlin dependencies using:

• Gradle (using build.gradle and build.gradle.kts files)

• Maven (using pom.xml files)

• Bazel (using WORKSPACE and install.json files)

• to detect dependencies not specified in manifest files

Gradle

To achieve the fastest and most accurate results, create a file containing the resolved dependency tree named .gradle.debricked.lock before scanning.

This can be accomplished using the technology in . If you execute the resolve command, the CLI automatically identifies all manifest files that lack the recommended Gradle lock files and generates them as needed.

You can create the recommended file(s) manually by running the Gradle dependencies command and saving the output in a gradle.debricked.lock file.

Every gradle.debricked.lock file should be placed in the same directory as its corresponding build.gradle or build.gradle.kts file.

Maven

To achieve the fastest and most accurate results, create a file containing the resolved dependency tree named .maven.debricked.lock before scanning.

This can be accomplished using the technology in our . If you execute the resolve command, the CLI automatically identifies all manifest files that lack the recommended maven lock files and generates them as needed.

You can manually generate the recommended file(s) by running the Maven dependency:tree plugin and saving the output to a maven.debricked.lock file.

Every maven.debricked.lock file should be placed in the same directory as the corresponding pom.xml file.

Bazel

OpenText Core SCA supports Java projects that utilize Bazel by scanning the WORKSPACE file format along with any Java file formats in use. To ensure fast and accurate scans, OpenText Core SCA recommends utilizing rules_jvm_external to generate an install.json file, which resolves and pins all indirect dependencies in a lock file.

For more information on setting this up in your project, see .

File fingerprinting

OpenText Core SCA supports scanning for Java dependencies not defined in manifest-files through file fingerprinting. Our database contains the hashes of .jar and .war files as well as their unpacked contents for all packages in the largest maven repository. This is used when comparing with the contents of your application, to ensure as accurate matches as possible.

For more information on file fingerprinting and how to set it up, see .

Supported file formats and features

*When building the knowledge base, the files are downloaded, unpacked and fingerprints are created for all file contents, except for certain excluded patterns. The fingerprints are created for the contents of each file. For example, OpenText Core SCA matches .dll files used in C# and .class files found within .jar files from Java, among others.

OpenText Core SCA supports tracking dependencies in CycloneDX SBOM using files in JSON and XML formats.

To ensure that OpenText Core SCA identifes the SBOM files as CycloneDX SBOMs, please name them using one of the following conventions:

• .bom..json

• .*cdx.json

• .*cdx.xml

• .bom..xml

The specific features available for the SBOM will depend on the libraries included and the individual package managers used.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

Analyzing external SBOM files using OpenText Core SCA - video guide

OpenText Core SCA now tracks JavaScript and TypeScript dependencies through:

• NPM (using package.json and package-lock.json files)

• Yarn (using package.json and yarn.lock files)

• Bower (using bower.json files)

• to detect dependencies not specified in manifest files

OpenText Core SCA recommends committing the lock files to achieve the most accurate tracking, as these files include the specific resolved versions of both direct and indirect dependencies. If you only commit the package.json file, OpenText Core SCA will update all dependencies to the latest available versions based on the specified version constraints.

If at least one supported file is committed to the repository, it will automatically be scanned for dependencies when you integrate with the CI/CD pipeline.

Bower

To achieve the fastest and most accurate results, create a file containing the resolved dependency tree before scanning. This can be accomplished using the technology in . By executing the resolve command, the CLI automatically identifies all manifest files that lack the recommended bower.debricked.lock files and generates them as needed.

File fingerprinting

OpenText Core SCA supports scanning for JavaScript dependencies not defined in manifest-files through file fingerprinting. The database contains the hashes of relevant files (including .js and .ts files) for all packages in the npm registry. This is used when comparing with the contents of your application, to ensure as accurate matches as possible.

For more information on file fingerprinting and how to set it up, see .

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

To grade the potential compliance risks involved with different licenses, we assess them using a grading system. Keep in mind that the color grading represents the estimated amount and complexity of the compliance concerns. This does not mean that some licenses are riskier than others - if you understand all the compliance requirements of a license and are able to fulfill them, then the license is practically risk-free regardless of our grading.

The risk levels are created under the assumption that the installed dependency is not affected by external factors, including, but not limited to, interactions with other dependencies and effects of compilation. We advise you to adjust the risk levels based on your own internal policies, risk tolerance and use case.

To read more about license families, license risks, use cases, and compliance - check out our blog.

OpenText Core SCA now tracks Ruby dependencies through RubyGems, using its associated Gemfile.lock files. If at least one of the supported files is committed to the repository, it will be automatically scanned for dependencies when integrated with OpenText Core SCA CI/CD pipeline.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

To ensure license compliance, we proxy non-standard license identifiers and references to SPDX identifiers and map deprecated license identifiers as accurately as possible. Below is a list of common deprecated licenses and how we proxy them:

If you have any further questions or need additional assistance, please refer to the or .

The goal of a Pull Request is to completely remove the CVE from the repository. Note that some dependency versions do not allow a safe version of the currently vulnerable dependency. Therefore, the pull request will only be generated if at least one of the affected direct dependencies has been updated to a safe version.

OpenText Core SCA currently supports two types of pull requests:

CVE-specific Pull Request

The pull request creation depends on the nature of the dependency relations. If updating the lock file suffices to fix the vulnerable dependency, the pull request will contain the updated lock file. If an update to the direct dependency is required, OpenText Core SCA will apply the fix to the main dependency file containing the direct dependency versions. Afterwards, OpenText Core SCA will update the lock file with the new version of the direct dependency and its dependencies.

When you generate a CVE-specific pull request, the following actions are performed to your repository and dependency files:

• Generate the dependency updates in the dependency file to fix the CVE.

• Make required changes to your dependency files as stated above.

• Create a branch in the repository.

• Push the remediated dependency files.

Repository-specific Pull Request

Repository-specific pull requests are a way of remediating vulnerabilities in bulk, with a single click of a button. Instead of focusing on remediating a specific CVE, OpenText Core SCA widens the scope to all CVEs that affect a specific repository. Currently, OpenText Core SCA only supports lockfile-only repository-specific pull requests. They are a quick way of making sure that your dependency files are up-to-date. These pull requests generate your lock file(s) from scratch in an attempt to update indirect dependency versions within given constraints. This will fix the majority of the CVEs in many cases. When generating a repository-specific pull request from the repository view, it will be based on the branch selected in the dropdown provided after clicking the Generate pull request button.

When you generate a repository-specific pull request, the following actions are performed to your repository and dependency files:

• Apply required changes to your dependency files as stated above.

• Create a branch in the repository.

• Push the remediated dependency files.

• Create pull request to original branch.

Lockfile-only fix

The lockfile-only fix means that you can regenerate the lockfile in your repository and the vulnerability will be solved. You don't need to update the root dependency - rather you should reinstall the same version (for example: run yarn upgrade and get a new lock.file). This is used when the version constraints set by the root dependency allow for the safe version of the indirect dependency, but it has been a while since you did the install. Then, re-installing it will solve the problem.

Branch selection

The type of pull request being generated determines what the new generated branch will be based on. If you’re generating a bulk fix from the repository view, the branch will be based on the branch selected in the drop-down provided after pressing the Generate pull request button. If you're instead generating a pull request from the page of a specific CVE, the chosen branch will depend on a few factors:

• If a default branch containing the CVE is detected in your repository, the pull request branch will be based on it.

• If OpenText Core SCA is unable to detect a default branch, or the CVE exists in a branch other than the default one for that repository, OpenText Core SCA will first check if the CVE exists in the main or dev branch. If not, the branch which contains the latest commit in the repository is selected.

For more information on how to solve a vulnerability using a PR in the web tool, click the below link:

In order to efficiently prevent vulnerabilities and unwanted licenses from entering your codebase, it is recommended to set up automation rules. The rules can be enforced in your pipelines, failing them or showing warnings, or set to notify relevant people, minimizing the number of vulnerabilities brought into your codebase.

You can see an overview of all automations in your organization by clicking the Automations on the left side menu. Here, you can create new automation rules, as well as edit or disable/delete the existing rules.

You can access automations for a specific repository by selecting a specific repository in the drop-down list.

To ensure transparency, OpenText Core SCA logs almost all events across the service. This enables you to track everything that happens in your company account and manage various aspects of security, performance, and transparency.

The logs can be accessed through OpenText Core SCA API, using the endpoints:

/api/{version}/open/admin/request-logs/get-request-logs/api/{version}/open/admin/request-logs/get-events

To get a list of event logs, simply call the get-request-logs endpoint with appropriate filters. Here is an example of a simple request, fetching all events:

curl -X 'GET' \'https://debricked.com/api/1.0/open/admin/request-logs/get-request-logs?start=2021-05-10T15%3A52%3A01&page=1&pageSize=20' \  -H 'accept: application/json' \  -H 'Authorization: Bearer <token>

In this case, a start date is specified, while the end date is not, which results in data on events from the start date, up to the current date and time. Since the endpoint is paginated, it is required to specify the pages and the page size.

Here is an example of a response:

The breadcrumbs list all the pages the user visited while using the tool. Note that the breadcrumbs are printed in reverse chronological order, that is, the latest event first and the oldest event last. The URLs in the breadcrumbs are relative to the event URL.

Filters

You can customize the logs by selecting additional filters, such as:

• userEmail - Filter events performed only by a specific user.

• url - Filter events only affecting a given URL. For example,

• eventTypeId - Filter a specific event type.

To filter the logs based on events and get a list of all event names and IDs, you can query the get-events endpoint:

Here is an excerpt of the response from the example:

It can be difficult to get a quick overview of all your repositories, especially if you have a lot of them. To make your life a bit easier, the OpenText Core SCA tool enables you to group repositories together, allowing you to organize your projects, e.g. based on team structure.

A group can consist of multiple repositories, but also other groups. It is also possible for one group to exist as a sub-group in multiple parent groups. Keep in mind that changes made to a group will have an effect in all places the group exists.

You can create groups from the repository view under Repositories. To create groups:

1. Go to Repositories on the left side menu.
2. Click + New and select Group.
3. On the New group window:

   1. Enter the Group name.

   2. Select the repositories for the group. You can associate multiple repositories to the group by selecting repositories from Choose repositories drop-down and creating new rows by clicking the plus button.

   3. Select the default branch for the repository. You can allocate default branch to the repository by selecting branch from

4. Select the relevant Groups.

5. Click Create.

Once created, the group will be shown with the name and aggregation of vulnerabilities in the linked repositories and groups. You can also view the default branch details in the repositories tab of repo groups.

Delete or edit a repository group

You can edit or delete a specific group by clicking on the three dots next to the group’s name. Clicking Edit will open the same view as when creating the group, enabling you to select or deselect repositories or groups included in the group. Keep in mind that if you delete a group, all groups that exist solely within this group will also be deleted.

Export repository group table data

You can export the filtered and visible data in the table to a CSV file. To do so, click Export Table located at the top-right corner of the table. For more information, refer to the topic.

Reachability Analysis is supported for all Go projects. You need the compiled code and the libraries used by your Go project to enable Reachability Analysis.

You need to generate a call graph to enable Reachability Analysis for Go. To generate a call graph, add the OpenText Core SCA CLI callgraph command to your integration before running a OpenText Core SCA scan. To find out more about the command and the various available flags, run:

debricked callgraph -h

When successful, the callgraph command generates a debricked-call-graph file. This file is automatically sent to OpenText Core SCA with the dependency files for analysis, when running the debricked scan command.

Set up call graph generation in your pipeline

For many projects, running the callgraph command with the default configuration might be enough to run the preparation steps. In this case, before running the debricked scan, to add the command to run debricked callgraph in your configuration to ensure that the scan has access to the generated call graph file.

For GitHub Action integrations, OpenText Core SCA must also add Actions setup that can be found in the .

Example: Building the project during the callgraph command

In this example, the callgraph command is run with default configuration to build the project and prepare the necessary files automatically before generating the call graph.

In order to delete your company account:

1. Click Admin tools on the left side menu.

2. Type your password.

3. Go to the Company settings tab.

4. Click Delete account and confirm.

After creating several commits or adding a repository with existing commits, it might be important to be able to look back and see the history of the changes. To see a list of all your commits and manage them:

1. Click Repository Settings on the left side menu.

2. Go to the Commits tab.

3. Click the repository you are interested in.

In this view, you can find a list of all your commits, along with the details:

• Name - The name of the commit.

• Commit Date - The date and time the commit was created.

• Repository - The repository the commit belongs to.

• Branch - The branch the commit was added to.

You can export the filtered and visible data in the table to a CSV file. To do so, click Export Table located at the top-right corner of the table. For more information, refer to the topic.

Delete a commit

If you decide you no longer want to see data from a specific repository and remove it, or if you revert a commit on your end, it might be useful to delete a commit from the list to clean up your data. To do so, click the trashcan icon on the far-right column.

Retention time of commit data

Unless you delete the commit data manually, non-default branches will be retained for 30 days, while default branches (main, master) have an unlimited retention period.

Additionally, enterprise users can tag selected commits as a release by adding the flag --tag-commit-as-release=true to the scan command in OpenText Core SCA CLI. Storing the commit data indefinitely (they can still be manually removed).

To enable Reachability Analysis for Java, you need to generate a call graph. This can be done using the callgraph command, which can be added to your integration, so that it is generated appropriately before making a OpenText Core SCA scan. To find out more about the command and the various available flags, run:

Reachability Analysis is supported for all Java projects using Maven. To produce a callgraph, OpenText Core SCA requires the compiled code for your project and access to the libraries it uses. By default, the command will attempt to do all the preparation work for the command to be successful. The success of the preparation depends on the specific project structure and configurations. In the event of failure, it is possible to configure the command not to run the preparation steps using the --no-build flag, and instead set it up separately before running the command.

When working with open source, it is crucial to ensure and maintain open-source compliance, also from a commercial perspective. To help with that, OpenText Core SCA provides you with a comprehensive overview of all licenses in the repositories you have integrated with us. You can find that information in different areas of the tool.

View all licenses

To view licenses, click License tab on the left side menu. Here, you can view the list of all your licenses in alphabetical order. The screen displays the following information:

OpenText Core SCA automation policies normally trigger based on pipeline events, such as committing a code to a repository. When the source code is committed, a OpenText Core SCA scan starts and automations run. However, in some cases, you might want to use automations to check the status of a repository even if you have not made any changes to it. For example, new vulnerabilities might be discovered for dependencies in repositories that are not updated regularly. Monitoring allows you to get timely warnings about issues in such repositories by automatically and periodically checking the rules regardless of pipeline events. It is possible to configure monitored automations to either result in webhooks or emails when triggered.

To enable monitoring for a new rule, follow these steps:

1. From a repository page, go to the Automations tab. On the Automations page, you can view the list of automation rules created.

Clicking Overview on the left side menu will take you to a dashboard allowing you to get a clear overview of all vulnerabilities found in your organization.

Filters

The security of a repository is crucial in many aspects of open source, as the security of a project determines the security of your product. This metric measures both indicators of vulnerability entry risk, and past vulnerability response performance. Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on the . You can find the data model illustrated below:

Vulnerability response

This practice describes how fast vulnerabilities are being handled in a repository. A high score means that maintainers and contributors solve vulnerability risks in a timely manner.

The following features of Vulnerability Response are measured:

To make things easier for you, OpenText Core SCA has created a set of default rules that are activated on your first scan and applicable to all of your repositories. As an administrator, you are also able to disable existing default rules and can assign new rules to be added to integrated repositories by default.

Keep in mind that once a rule is marked as default, it will be enabled for new repositories, even if it was disabled for existing repositories.

Set a rule as a default rule

Access tokens are a secure way of performing automated integrations with OpenText Core SCA. They are safer compared to using a username and password, and their typical use cases include GitLab, Bitbucket, and API integrations, which are not tied to a particular user, but rather to a repository or a project.

To generate a new access token:

OpenText Core SCA's algorithms constantly scan various sources for information about vulnerabilities, licenses and health data. These include (but are not limited to: the NVD Database, NPM, C# Announcement, FriendsOfPHP's security advisories, Go Vulnerability Database, PyPA Python Advisory Database, GitHub Issues, GitHub Security Advisory, mailing lists, and more. OpenText Core SCA checks the sources every 15 minutes, giving fast and accurate data.

Data refinement

When the data is collected, it is cleaned up since it is often quite messy. As the sources are a combination of structured and unstructured data, there are a lot of errors in it by default.

OpenText Core SCA's Reachability Analysis helps you automatically determine if a vulnerability in a library affects your project. It analyzes which parts of the library are vulnerable and checks if your code uses those parts. To do this, OpenText Core SCA needs to understand how your open source dependencies are used. This information is collected by using OpenText Core SCA's CLI tool to generate a call graph for your project. For instructions on creating the required call graph, see how to .

Finding the right open source project to solve your specific problem can be difficult, especially when you want to make informed decisions before choosing what to bring into your codebase. is OpenText Core SCA’s database of all open source projects available on GitHub. It enables you to search, compare and evaluate packages based on different health metrics and quality scores.

How do i search?

With Open Source Select, you can search for packages, projects or functionalities and get all relevant information presented in one place. You can further refine your search using filters.

When searching, use a few good keywords describing what you're looking for. For example, try searching for “frontend graphs” if you're looking for a project to help you create nice-looking visualizations, or search for “message broker” if you're looking for data streaming projects.

In order to edit a user account:

1. Go to Admin tools on the left side menu.

2. Type your password to enter the administrative mode.

3. In the Users tab, click the Edit (pen icon) next to the user.

The first time you visit the License view; you will notice that the value in the risk column is set to Unknown for all licenses. This is because you have not yet configured any use cases for your repositories.

To do that:

1. Go to Repository Settings in the left side menu.

2. Under the column Use case, click on Unknown in the row of the specific repository.

Assume there is repository with huge number of vulnerabilities. It will take time to go through each one of them and potentially fix them. OpenText Core SCA offers the ability to open a pull request to solve many vulnerabilities at once.

Support for Pull Requests

Currently, OpenText Core SCA only supports pull requests for certain package managers and integrations using the GitHub app, GitLab or Azure DevOps. For information regarding the support of your package manager, see the .

The Legacy CLI has now been deprecated. By April 2nd 2024 using it will result in pipeline failures, and the scans will be completely turned off on May 2nd 2024. If you're interested in integrating with us using our CLI, please check out the documentation for . If you’re a user of the Legacy CLI, learn how to .

If you want to get the most out of OpenText Core SCA tool, setting up an integration is the preferred way of working with your repositories.

However, if you want to test a specific dependency file for vulnerabilities, you can do so by manually uploading the file(s):

1. Go to Repository Settings on the left side menu.

2. Click Manual scan on the top right area of the table.

3. Upload the file(s) you want to scan.

4. Click Start scan.

5. Once the scan is completed, click View results to see all discovered vulnerabilities.

This action will create a repository named "[email protected] - <date>" and will add this scan as a commit within a repository.

You can flag a vulnerability as snoozed for a set amount of time. By doing so, the specific vulnerability will not be triggered in any automation rules for the specific repository. After the chosen snooze duration expires, your automation rules will again take the before snoozed vulnerability into account and respective actions will be triggered again.

Snooze a vulnerability for a set amount of time

To snooze a vulnerability:

1. Go to the vulnerability page.

2. Click Pause rule triggering in the Action section.

1. Select Snooze for a set time period in the newly opened dialog and select your desired snooze period.

1. Click Save to confirm your selection and snooze the automation rules for the vulnerability.

You can see the activated snooze being shown as review status under Action. Snoozing the vulnerability is also reflected in the Activity section at the bottom of the page.

Though any user is able to choose "snoozed" as review status by default, as an admin, you can disable this feature for all users in your company.

Manually remove a snooze from a vulnerability

You can manually stop snoozing a vulnerability at any time before it resumes automatically:

1. Go to the vulnerability you want to resume.

2. Click Snoozed for (time) and confirm that you want to stop snoozing the vulnerability in the displayed dialog. Note that this will enable automation rules to be triggered for this vulnerability again.

Pause review status

You can flag a vulnerability as paused in a specific repository. The vulnerability will stay paused until a fix is found, if applied, resolves the vulnerability in your repository. In that case, the paused status will be removed automatically, and the vulnerability resumes to being unexamined.

Keep in mind that the pause could potentially be indefinite when a fix is never found. It is recommended to choose a maximum pause time when setting this review status. If the pause duration expires before the fix is found, your automation rules will resume taking the vulnerability into account. This is similarl to how snoozing a vulnerability works.

Pause a vulnerability until a fix is available

To pause a vulnerability until a fix is available:

1. Go to the desired repository and vulnerability to pause.

2. Select Pause rule triggering in the Action section.

3. Select Pause until a fix is available in the opening dialog and choose an appropriate max pause time.

4. Click Save to confirm your selection and pause automation rules for the vulnerability.

You can see the activated pause being shown as review status under Action. Pausing the vulnerability is also reflected in the Activity section at the bottom of the page.

Manually remove a pause until a fix is available from a vulnerability

You can manually stop pausing a vulnerability at any time before a fix is found or the max pause time has expired.

To manually remove a pause:

1. Go to the vulnerability you want to resume.

2. Click Paused until fix and confirm that you want to stop pausing the vulnerability in the displayed dialog. Be aware that this will enable automation rules to be triggered for this vulnerability again.

Knowing what kind of licenses you have imported through your dependencies is crucial, as failing to comply with open-source licenses puts you at legal risk. OpenText Core SCA allows you to make an export with all licenses and the affected repositories. This enables you to let relevant stakeholders get an easy overview of the state of compliance and keep track of your progress over time.

Generate a license export

1. Click Generate Export on the top right corner of the page.

2. Select the scope of the export as wither global, repositories or groups.

3. Under Export Type, select License Export.

Depending on the selected scope, you might receive three different types of exported data:

all_licenses.xlsx

The excel sheet is divided into three columns:

• License - The name of the license.

• Repositories - The name of the repository using that license, the latest commit hash, and the creation date of that commit.

• License family - The name of the license family.

licenses_per_repo.xlsx

The excel sheet contains the name of the repository in the first row, divided into five columns:

• Dependency - The name of the dependency.

• Dependency id - The ID number of the dependency.

• License - The name of the licenses used by the dependency.

• Version - The version of the dependency.

licenses.xlsx

The excel sheet contains the name of the license in the first row, divided into two columns:

• Repositories - The name of all the repositories using that license.

• Dependencies - The name of all the dependencies using that license per repository.

What is CycloneDX?

CycloneDX, developed by the Open Web Application Security Project (OWASP), is an open common standard for communicating SBOM information, a data format.

Dependency relations

In the dependencies array, you can find a reference number (ref) for each component and an array of each direct dependency of that dependency (depends_on). The roots of the relational trees will reference to the files in the project, together with the direct dependencies that it contains. By traversing the dependencies array, it is possible to build the entire dependency tree.

In example below, you can see the direct dependency `webpack:4.28.4` depending on `terser-webpack-plugin:1.2.1` which in turn depends on `terser:3.14.1`.

Here is how this would be visualised in the user interface:

Root fixes

Under Recommendation, you can find information about the first version of the specific vulnerable dependency that is safe, as well as the first version of the root or direct dependency that does not contain a vulnerable version of the indirect dependency. See example below:

A strong password is an easy and effective way to protect your account.

To change your password:

1. Hover on your name at the bottom of the left-side menu.

2. Click User profile.

3. Under Personal settings, type your new password and verify using your current one.

4. Save the changes.

OpenText Core SCA currently supports the tracking of C# dependencies through:

• , using .csproj, packages.lock.json and packages.config files

• , to find dependencies not defined in manifest-files

Open-Source projects are affected by contributors. Theyhave the power to make a project thrive or die. When deciding what open source project to bring into your software, it is important to inspect and analyze its contributors.

Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on the . You can find the data model illustrated below:

Contributor experience

This practice describes the contributor's experience in a specific repository. Experienced contributors tend to write more efficient, more secure, and usable code, and are therefore preferred.

What is an SBOM?

A Software Bill of Materials (SBOM) is a record of the supply chain relationships between the components used when creating software. The record lists all components of a product, including all open source software, which can be helpful for both the developers and other stakeholders, such as investors and legal teams.

You can assign user roles to customize the way you and your organization work. For customers, there are two user roles available, admin and user.

Here are all the actions available for each user role:

Manage your repositories

1. Click Repository Settings on the left side menu.

1. Go to Automations on the left side menu (You can also access automations for a specific repository by clicking the Automate button on the top right corner).

2. Click the +New button, then +New rule.

3. Select the repository(s) you want the rule to be applied to.

OpenText Core SCA supports tracking Go dependencies through:

• Go Modules, using go.mod files

• Go Dep, using gopkg.lok files

• Bazel, using WORKSPACE

What is SPDX?

SPDX is an open standard for communicating software bill of material information, including provenance, license, security, and other related information. SPDX reduces redundant work by providing common formats for organizations and communities to share important data, thereby streamlining and improving compliance, security, and dependability.

Cancel your subscription

If you are not satisfied with the current premium offering, you can .

To cancel your premium subscription:

1. Go to Billing

Add a new user to your company

1. Go to Admin tools on the left side menu.