Skip to content

[Sensitive Information] US Passport Number - #58

Closed
v1ktor0t wants to merge 75 commits into
mainfrom
veles-us-passport-number
Closed

[Sensitive Information] US Passport Number#58
v1ktor0t wants to merge 75 commits into
mainfrom
veles-us-passport-number

Conversation

@v1ktor0t

@v1ktor0t v1ktor0t commented Jul 3, 2026

Copy link
Copy Markdown
Member

Related to #57

I merged the behavior of both branches. Once this one is reviewed, the other PR/branch can be removed.

Comment thread binary/proto/scan_result.proto Outdated
string key = 2; // OAuth Application Secret (prefix: sq0csp-)
}

message USPassportNumber {

@alessandro-Doyensec alessandro-Doyensec Jul 6, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need to create a proto type for these, since the type is always sensitiveinformation.SensitiveInformation

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oversight from the merge. i'll remove it now

@alessandro-Doyensec

alessandro-Doyensec commented Jul 6, 2026

Copy link
Copy Markdown
Collaborator

I think this collides with #57

Yes it does, beside the .proto looks ready to be merged

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are the proto changes required?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there was a letf-over proto object that was not needed, but compiled in. the new version contains the up-to-date compiled proto objects

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that proto objects are not modified by the PR after all, can't we just leave them as-is?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i had a wrong assumption about this. reverted the file to the version in main,

Comment thread docs/supported_inventory_types.md
FromMatch: func(blob []byte, keywordMatch bool) (sensitiveinformation.SensitiveInformation, bool) {
likelihood := sensitiveinformation.LikelihoodUnlikely
if keywordMatch {
likelihood = sensitiveinformation.LikelihoodVeryLikely

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am willing to bet they'll want to downgrade it to LikelihoodLikely. VeryLikely is rather for stuff we were able to verify checksum, or something similar.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch.


var (
keywordsRe = simpleregex.KeywordsRe([]string{
`\b\w*passport\w*\b`,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is \b\w*passport\w*\b different from just passport ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the basic idea is to match passport within a boundary with an arbitrary prefix and/or suffix. for example, that regex will match all of these:

  • passport
  • passport_no
  • us_passport
  • us_passport_num

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. But isn't the same achieved by just using passport?
In other words: can you point out what is filtered out by this construction?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

technically yes, with the exception that i'd need to remove the boundary (\b). let me see if there's any space for some optimization

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SzymonDrosdzol made some updates. i'd appreciate a look when you get the chance

@SzymonDrosdzol SzymonDrosdzol mentioned this pull request Jul 6, 2026

@alessandro-Doyensec alessandro-Doyensec left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀

Nit: you can rebase the whole PR to completely remove any changes done to the proto files inside commits, that way you don't have merge conflicts

@SzymonDrosdzol SzymonDrosdzol left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀

@v1ktor0t
v1ktor0t force-pushed the veles-us-passport-number branch from 7bd9574 to 0274912 Compare July 13, 2026 08:04
SCALIBR Team and others added 20 commits August 12, 2026 10:32
… in extracted packages.

PiperOrigin-RevId: 945701840
…nges in working directory instead of based on HEAD.

Effectively, this change uses the programmatic equivalent of `git ls-tree HEAD` to determine the submodule SHA instead of the current `git submodule status`. A good explanation of the difference can be found here: https://stackoverflow.com/a/54238999

Falls back to using `git submodule status` when the SHA cannot be determined with the other method.

PiperOrigin-RevId: 945863104
Extractor was updated to parse package information & line number in a single-pass with a line-by-line scan, vs. using common MIME parsing library that doesn't have line number tracking.

PiperOrigin-RevId: 948472912
The regex used to match per-requirement option was too aggressive,
causing "-C" inside valid package names to be matched and trimmed into
the wrong package names.
Adding leading whitespace or new-line to the regex to prevent this issue

PiperOrigin-RevId: 950622262
PiperOrigin-RevId: 951144571
…PURL

ID=sles now emits SUSE ecosystem and pkg:rpm/suse/ namespace.
ID=azurelinux and ID=mariner now emit Azure Linux ecosystem and
pkg:rpm/azurelinux/ namespace.

Alpaquita (ID=alpaquita, APK) was already correctly routed.

Fixes silent false-negative on OSV.dev for 20,561 SUSE advisories,
12,016 Azure Linux advisories, and 9,157 Alpaquita advisories.

Routing table added:
  ID=sles       → SUSE ecosystem,        pkg:rpm/suse/
  ID=azurelinux → Azure Linux ecosystem, pkg:rpm/azurelinux/
  ID=mariner    → Azure Linux ecosystem, pkg:rpm/azurelinux/
- Added sorting to transitivedependency (pomxml, requirements) enrichers for deterministic inventory ordering.
- Add sorting to grpc queries to make it consistently snapshotable
- Updated package name resolution in vulnmatch (osvdev, osvlocal) to handle GIT repo names, Go stdlib, and source/origin names for dpkg/apk packages.
- Updated package version resolution to take into account redhat epochs.
- Added support for purl TypeBrew and "git" ecosystem conversion in extractor.
- Updated SPDX extractor to set package version from PURL and updated spdx_test.go.
- Add support for the GIT ecosystem

PiperOrigin-RevId: 951216522
ID=opensuse-leap from /etc/os-release fell through the rpmmeta.Metadata
switch with no case, producing an empty ecosystem string and making all
12,954 openSUSE OSV advisories unreachable.

Add a dedicated branch that constructs the suffix as "Leap " + VERSION_ID,
matching the format used by OSV.dev (e.g. "openSUSE:Leap 15.5").
Using VERSION_ID alone ("15.5") does not match any advisory.

The EcosystemOpenSUSE constant was already defined in
inventory/osvecosystem/parsed.go but never referenced in ecosystem.go.

Fixes: google#2203
rahulhoysala and others added 29 commits August 12, 2026 10:33
Updated package comment to include PEP 621 compliance and details about parsing specific tables.
PiperOrigin-RevId: 958255624
… a common directory for use in other language extractors.

PiperOrigin-RevId: 959048498
…ctly instead of strings.

PiperOrigin-RevId: 959257339
PiperOrigin-RevId: 960740927
…kages in SCALIBR

PiperOrigin-RevId: 960924505
…fests optional.

PiperOrigin-RevId: 962662583
…tracted from Java manifests.

PiperOrigin-RevId: 962743048
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.