A new field in the packages object

[floydtree]

Currently package object does not have a field in place to account for package manager information. This information is provided by log sources such AWS Inspector in the context of a vulnerability scanner.

I propose we add a string field named package_manager in the package object.

    "package_manager": {
      "caption": "Package Manager",
      "description": "The software packager manager, e.g. npm, yum, dpkg etc .",
      "type": "string_t"
    },

[jp-harvey]

I may be misunderstanding the use case, but package -> package manager is (or can be) a one-to-many relationship - eg. yum and dnf are both package managers for rpms. So having what looks to be a 1:1 field does not fit, unless it's there to specify which package manager to use? It seems a log source for vulns should not be opinionated about that though.

[floydtree]

Yeah, I think it's a bit of misunderstanding. It's neither of the 2 scenarios you have mentioned. This info comes from the log source - the vuln scanner itself, indicating which package manager was used to source the package on the specific host via the underlying endpoint agent.

[jp-harvey]

Ah gotcha. I can see the Package object being used in other classes though in the future. By the description my intuition was that a package is something that exists independently of it's installed status. For example the vim-common-7.4.629-7.el7.x86_64.rpm package is an object that is defined by (among other things) it's checksum and name, and is installed in many places.

In many nosql / document datastore implementations this distinction does not make much of a difference, since often data is stored in discrete blobs without joins. In a traditional RDBMS (which we should not be ignoring when designing a schema) when looking to minimize data redundancy and enforce referential integrity, the tables are joined and how different objects are related to each other is core to the design. There are also many nosql implementations that adopt the object relationship approach in order to minimize storage usage too.

It would cover all use cases and package becomes a more reusable object if we had something like an installed package object that had attributes relating to the installation of that package, one of those attributes being the Package object, and another being package_manager, maybe install_date etc.

So creating an installed_package object is my vote.

[irakledibm]

I agree, Package probably should be independent from the context in which particular instance of it was used.

[floydtree]

Interesting, I can go either way.
This is what I am currently thinking though, we should encourage object reusability instead. The context in which the object is used should provide meaning, instead of creating new objects for different contexts. For example, in the security findings class, packages is used to represent data about vulnerable packages as reported by the source. Now do we create a new object - vulnerable_packages? I don't think we should. Considering, the actual data itself will be overlapping, we don't need multiple objects. I think we should use the same object and override descriptions at an event class level. Coming to the package_manager field, we can modify description to be more specific to convey it is referring to the source of the installed package. Happy to discuss further.

[jp-harvey]

That's a good point about reuse. I don't see it in Security Finding but maybe I'm getting my profiles etc. wrong or looking at the wrong version though. Agreed that packages represented in a Security Finding should not need a new object, following the installed_package model it would be an array of installed_package objects and then reused between the two classes. We get more re-usability by decoupling the package manager from the object.