openshiporg/openship: technical due diligence, read from its repository

In the last 24 months, 2 of 69 commits (2.9%) carry any trace of review: a merge, a pull-request reference, a Reviewed-by or Reviewed-on trailer, a Closes/Fixes reference, a maintainer's sign-off on someone else's change, or a change applied by someone other than its author. That is low but not absent. Review may happen in a workflow this history does not record; a buyer should ask how change is approved before it ships.

3 test files against 510 source files (0.6%). This does not measure whether the tests are good, only whether enough of them exist for the codebase to be changed safely by someone who did not write it — which is exactly the situation after an acquisition.

package.json declares 83 direct dependencies. Each one is a maintenance obligation, a supply-chain surface and a potential licence question that transfers with the asset. The count says nothing about whether any given dependency was a good choice; it says how many such choices a buyer inherits.

There is no disclosure policy, no automated dependency updates, no named code owners and no pre-commit configuration. None of these is load-bearing on its own. Their collective absence says that security posture here is whatever the current team happens to remember to do, which is not a posture that survives the team changing.

32 of 1,014 locked dependencies match 145 published advisories in OSV, 66 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version.