DEVELOPER NOTES: After some internal discussion with the team, we think implementing this feature would be good but an implementation should consider a few things:

• we do not want the location to be output by default in the table view, as locations can be (and often are!) very long, this would make the table unwieldy, which is contradictory to the purpose of the table: having a simple summary view. however, we could make the columns that get displayed configurable (e.g. columns=name,vulnerability,location) but since table is a format type, a flag like --table-columns is mutually exclusive to the other output formats and we'd like to avoid this, instead favoring just structured configuration (like env var GRYPE_FORMAT_TABLE_COLUMNS=... or analogous YAML)
• syft format configuration is done using a pattern consistent throughout the application in a number of ways: get a list of preconfigured format providers to pick from rather than configuration resulting in a single formatter object. we should probably use this feature to rework the grype presenters to be configured and used similar to the syft formats in this regard.
• we probably want to continue to output 1-line-per-result. some possibilities for solving the "very wide table" problem could involve putting locations on a second line or similar, but this would break any tools using the table output as a simple way to get a list of CVEs using something like cut
• as noted in the PR feat: include file location in table output (#1199) #1275, it also could be nice to have a configuration for omitting certain types from the location by default, such as rpm or dpkg packages, which tend to reference the same file(s) and provide limited value

One note I'll add is that I actually think Trivy has solved this problem really elegantly in their table output.

They don't cram all vuln matches of all kinds into a single table, they create "context-relevant" tables for distro packages and individual files.

Here's a simple example:

In this case, they found vulnerabilities in just one file. Instead of putting that file path (which to your point, could have been very long) inside a column somewhere, they factor it out and give the path its own table.

This is hugely beneficial to someone trying to use the tool to get real remediation work done.

For the example above, Grype just shows github.com/docker/docker. And the image could have had hundreds of binary paths to look in. Asking users to "use the JSON output" would solve their problem, but at an enormous cost of verbosity. Taking an approach like Trivy's would make the table more valuable without incurring much cost.

Food for thought!