Repository navigation
Secord ignore rule with a PURL not taken into account when snippet-matching an Open Source project #120
Description
Hi @mscasso-scanoss! As discussed, here's the summary of the issue in written form:
We are using ORT Server to run snippet scans via SCANOSS. When scanning the https://github.com/nordic-institute/X-Road Open Source project ( the develop branch), we get several snippet findings that point to the X-Road project itself, which we'd like to filter out / ignore, in order to only get snippet findings from third-party projects.
One of the findings we get is for the file deployment/security-server/images/base-images/auxiliary-service/files/usr/share/xroad/scripts/containerised/autobackup.sh, which in line 12-18 contains code from src/packages/src/xroad/common/proxy/usr/share/xroad/scripts/get_security_server_id.sh in the same project:
To filter out such findings, we are adding the PURL pkg:github/nordic-institute/x-road to the ignore rules of the SCANOSS Java client API. That works for this first PURL, but a new scan still shows findings from the X-Road project, this time e.g. for deployment/central-server/k8s/charts/central-server/templates/_configmap.tpl, which now is a full-file match:
So we are adding a second PURL pkg:golang/github.com/nordic-institute/x-road to the list of PURLs to ignore, but this time adding that PURL has no effect, we still get the same number of snippet findings.
To verify that the PURLs are correctly passed from the ORT Server UI to the SCANOSS API Java client, I've checked the logs, and it seem that the PURL to ignore do get recognized:
time=2026-10-13T18:14:33.193 thread=virtual-274 traceId=e5c26006-a514-4c3f-bc7f-2ff777741c89 ortRunId=2107 component=scanner-worker scannerJobId=1417 level=INFO logger=com.scanoss.rest.ScanApi message="ignore rules detected. Converting to legacy rules {\"components\":[{\"purl\":\"pkg:github/nordic-institute/x-road\"},{\"purl\":\"pkg:golang/github.com/nordic-institute/x-road\"}]}"
Could you please investigate if this could be a bug on the SCANOSS side? Thanks in advance!
Activity
mscasso-scanoss commentedon Oct 23, 2026
Hi @sschuberth, thanks for the detailed report. We tried to reproduce it, but on our side the second ignore rule works as expected, both in the engine and in the SCANOSS Java client.
What we tested
We used the
developbranch of X-Road (e98798e; both files you mentioned are unchanged since well before your scan) against our production API, with the same ignore rules as in your log:pkg:github/nordic-institute/x-roadpkg:golang/github.com/nordic-institute/x-roadWe scanned through the engine directly, through scanoss-py, and through scanoss-java 0.13.1. For the Java client we built the settings the same way ORT's
ScanOss.buildSettings()does.Unmodified, both files are full-file matches. Your first example was a snippet match, so we also forced snippet matching by adding a comment line at the top of every file. That changes the file hash, so the engine has to resolve the files through snippets. In both cases the ignore rules work:
autobackup.sh_configmap.tplpkg:golang/…/x-roadpkg:golang/…/x-roadpkg:golang/…/x-roadpkg:golang/…/x-roadpkg:golang/…/x-roadpkg:golang/…/x-road(
_configmap.tplis too small to produce a snippet match once modified.)We got the same result for the whole repository (about 5,450 files) against production:
The remaining findings point to older copies and forks of X-Road, such as
pkg:github/ria-ee/x-road(the original repository),pkg:github/rrojasintexus/xroad-coandpkg:github/bthj/x-road. You may want to add those to the ignore list as well.Since we can't reproduce it, our guess is that the ignore list didn't reach the API in your second run. One possible cause is scanoss/scanoss.java#47: if the scan settings also contain include rules (in ORT these come from snippet choices with reason
ORIGINAL_FINDING), the client drops the ignore rules entirely. To narrow it down, could you share:ignore rules detected ...log line in that run is followed byinclude rules detected. Converting to legacy rules ...;_configmap.tpl.sschuberth commentedon Oct 23, 2026
Thanks for the testing. I meanwhile got reports from @willebra that it also started to work on our side, and we were assuming that you did some fixes on your end. Can you confirm @willebra?
willebra commentedon Oct 25, 2026
Thanks @mscasso-scanoss for the thorough reproduction. Yes, I can confirm that the ignore rules work on our side now, but they did not on October 13/14, with identical input on our side.
I've used my AI agent to collect data:
Before and after
All runs scan X-Road
developthrough ORT Server with the SCANOSS plugin as a project scanner,chosenSnippetModel: LICENSE_AND_COPYRIGHT_FINDING,SNIPPET_FINDING.ignorePurlspkg:github/nordic-institute/x-roadpkg:golang/github.com/nordic-institute/x-road,pkg:github/nordic-institute/x-roadpkg:github/ria-ee/x-road,pkg:github/bthj/x-road,pkg:github/rrojasintexus/xroad-copkg:github/andcolombia/xroad-coNote that in run 2113 even the GitHub PURL, the first rule, had no effect: 1013 of the 1024 findings had
pkg:github/nordic-institute/x-roadas their primary PURL.Answers to your questions
ignore rules detected. Converting to legacy rules {...}with the configured PURLs, and none logsinclude rules detected. Ignore list was sent astype=blacklist..ort.ymlhas nosnippet_choices. Also, for project scans ORT runs SCANOSS as a path scanner whoseScanContexthas nocoveredPackages, soScanOss.buildSettings()produces no include rules at all.buildSettings(), theignorePurlsoption) is unchanged in that range.pkg:github/nordic-institute/x-road, 918 of them full-file matches. The remaining 11 were third-party (eclipse-edc, BouncyCastle, etcd-io/jetcd, jonapoul/atlas-gradle-plugin).Since the client sent the same request in runs 2113 and 2187, our assumption is that something changed on the API / engine / knowledge base side between October 14 and 22. Can you confirm whether anything was deployed in that window? That would help us document which behavior to expect.
Follow-up: ignoring forks one at a time
As you suggested, we added
pkg:github/ria-ee/x-road,pkg:github/bthj/x-roadandpkg:github/rrojasintexus/xroad-co(run 2194). Those three PURLs disappeared, but 10 of the 12 files they matched were then attributed to yet another fork,pkg:github/andcolombia/xroad-co:src/common/common-admin-api/.../audit/RestApiAuditEvent.java:4-214src/common/common-admin-api/.../audit/AuditEventLoggingFacadeImpl.java:4-252src/common/common-core/.../util/MimeUtils.java:5-172src/common/common-message/.../util/HttpSender.java:5-155src/lib/globalconf-core/.../util/FISubjectClientIdDecoder.java:4-156src/security-server/admin-service/.../service/ServiceService.java:6-277src/security-server/admin-service/ui/src/global.ts:5-229src/service/proxy/proxy-core/.../ProxyMonitorServiceHandlerImpl.javasrc/service/message-log-archiver/scripts/demo-upload.pl(full file)src/service/proxy/proxy-dsp-core/.../AgreementGrant.java:4-8src/security-server/admin-service/.../service/ClientService.java:5-1060src/service/proxy/proxy-monitoring-api/src/main/resources/monitoring.wsdl(full file)The upstream paths in the forks use X-Road's older layout, e.g.
RestApiAuditEvent.javamatchessrc/proxy-ui-api/src/main/java/org/niis/xroad/restapi/config/audit/RestApiAuditEvent.javain andcolombia/XROAD-CO. (The X-Road revisions differ slightly between the runs sincedevelopmoved, but the matched files and line ranges are nearly identical.)Adding
pkg:github/andcolombia/xroad-coas well (run 2208) removed all 10 of its matches, and this time no other fork took over. So for X-Road it took one run per fork, four forks in total, to get rid of the self-matches. For a project with many forks, ignoring by PURL becomes a trial-and-error loop, since each ignored component can be replaced by the next-ranked copy of the same file. Questions:ignore?pkg:github/nordic-institute/x-roaditself, which contains the same code? Would declaring X-Road as an included (identify) component help, and is that compatible with ignore rules once Ignore rules are silently dropped when include rules are also present scanoss.java#47 is fixed?demo-upload.pl, the same full-file match reports MIT under ria-ee/x-road and NOASSERTION under andcolombia/xroad-co. Is the reported license that of the component rather than the file?Third-party matches also changed between October 22 and 25
Between runs 2194 and 2208, matches to components that are not on the ignore list also changed, for files that are unchanged in X-Road between the two scanned revisions (
67046f6cand38cd99ec). Our side was unchanged as well: same SCANOSS options apart from the added fork, scanoss-java 0.13.1, no SCANOSS plugin changes between ORT 97.1.0 and 97.2.0, and the log again shows only the ignore rules and no include rules.src/service/ds-identity-hub/.../provisioning/ParticipantCredentialRecordsPurger.java:30-98pkg:maven/org.eclipse.edc/identity-hub-credentials-store-sql, Apache-2.0, 69% (SqlCredentialStore.java:18-86)src/lib/rpc-core/.../rpc/client/DeadlineInterceptor.java:31-34pkg:golang/github.com/etcd-io/jetcd, 5%src/service/ds-control-plane/.../policy/PolicySubjectMatcher.java:31-36pkg:maven/org.eclipse.edc/policy-engine-lib, 5%src/service/ds-control-plane/.../provisioning/ParticipantContextConfigDeleter.java:32-36pkg:maven/org.eclipse.edc/identity-hub-keypair-store-sql, 5%src/common/common-core/.../util/X500Names.javapkg:maven/org.bouncycastle/bcprov-jdk14,LicenseRef-scanoss-bouncy-castle-licence-10684, 18%, lines 31-36 and 75-86pkg:github/bcgit/bc-java, MIT, 20%, lines 29-36 and 75-86The eclipse-edc matches to other files (
ReusableAgreementLookup.java,ConsumerDataFlowCompletionListener.java,RecordingEdcHttpClient.java, theServiceExtensionfile) andbuild.gradle.kts→jonapoul/atlas-gradle-pluginare unchanged.Did something change in the engine, ranking or knowledge base between October 22 and 25 that explains why it is no longer reported? Or could the added ignore rule for
pkg:github/andcolombia/xroad-coaffect matches to unrelated components?Release 6.1.0-crc64: ignore related purls, license overflow fix, snip…
fix: related-purl ignore + normalize_license overflow + snippet fallb…
fix(ignore): suppress components ignored by a related purl (#120) (#125)
mscasso-scanoss commentedon Oct 28, 2026
Hi @sschuberth, a follow-up on the
ignorefeature: we changed how the engine applies the ignore list. The change is released in engine v5.4.28 (#126).What changed
pkg:github/nordic-institute/x-roadandpkg:golang/github.com/nordic-institute/x-road), only gets its other PURLs at report time, so ignoring one of those related PURLs had no effect. The engine now drops a candidate component if its primary or any related PURL is in the ignore list, before choosing the best match.none. The engine now retries that file once as a snippet scan, honoring the same ignore list, so a legitimate third-party snippet match can still show up.Both changes only apply when an ignore list is sent; scans without one are unaffected.
What this means for your ignore rules
pkg:github/ria-ee/x-roadorpkg:github/andcolombia/xroad-co) can still show up and need their own rules.Let us know if you see anything unexpected with the new behavior.