Explicit instruction isn't necessary or desired, it's trivial to write a unfunded 'compliance' requirement, practically guaranteeing a specific outcome.
There is a technical or moral concern that does not immediately make money, or worse, reduces income.
Every development sprint tasks are prioritized.
All that needs to happen is for the desired items to have, say, a priority of 3, while items in the sprint are always priorities 1 and 2.
That ensures those items are never done.
Examples? Google web applications tested and bugs fixed for Firefox.
If that person, and that person's management, think that security and privacy are a priority, then things get fixed.
As long as there's no incentive to improve security, there will be no security.
Examples of incentive: laws. Fix security or you can't sell your product, if you can't sell product you don't get a bonus or get fired. Don't gather location data if it's not critical for the functioning of the car or you can't sell your product, etc.
Surely it’s all about risk mitigation; some out-of-date NPM package with a minor flaw might cause the can to be kicked, but a major flaw with demonstrable consequences should get priority.
Arguably they'd be better off actually doing that as a true buyer and just engaging B2B for their easily solved CRUD variants than this weird go-between that combines the negatives of managing employees with the negatives of buying unknown solutions.