Define ECS set of fields for (runtime) dependencies

[simitt]

Defined fields for software dependencies in ECS. Auditbeat already collects information around installed packages and can be used as starting point:

auditbeat system/package:
system.audit.package.entity_id
system.audit.package.name
system.audit.package.version
system.audit.package.release
system.audit.package.arch
system.audit.package.license
system.audit.package.installtime
system.audit.package.size
system.audit.package.summary
system.audit.package.url

---

Update: PRs implementing package specs:

• ECS software packages and runtime dependencies #532 main PR covering agreed on package fields
• Add url to package definition #585 package.url
• Add extended_version to package definition #586 package.extended_version
• Add type to package definition #587 package.type

[Qard]

In the case of the Node.js APM agent:

• name, version, license , summary should all be easy to collect
• Sometimes we'll have something useful for url
• size would be rather difficult/expensive to get

Everything else is not really relevant to Node.js, in my opinion.

[webmat]

Good idea, thanks @simitt!

If the APM team needs this, a pull request would be really appreciated. Packages aren't on the top of the priority list over here, but we're definitely able to help hammer out a PR and get this merged in, if someone is willing to do the legwork :-)

@Qard That's all good. The idea is to define fields that make sense when looking at the broad picture. Then we fill as many as reasonable, depending on package type. If the size isn't readily available, it would be skipped.

Speaking of which, we may want to have a field package.type to track which kind of package this is: system, node, ruby, etc...