On a Magento project, There are three different kinds of code:
- Magento core
- Custom modules from my team
- Extra packages pulled in through Composer
For the first two, trust is simple.
I can trust Magento core.
There is a vendor, a security team, a release process.
If we stay on supported versions and install security patches, we know roughly how safe we are.
I can also trust my own team's code.
I know who wrote it.
I can read it.
I can review pull requests and run tests.
If something breaks, we know who can fix it.
Dependencies are not like that.
Every Composer package is code from people we do not know, with release schedules we do not
control.
One package can pull in many other packages inside it. After a few years, the project runs a lot of
code nobody on the team has ever really looked at.
This is where composer.lock becomes important.
- Which packages are installed
- Which exact versions
- Where they come from (official source or some Git repo)
- Which PHP version and extensions they need
- Which Composer plugins are allowed to run
A dependency audit is just this: take that list seriously.
- First, list what is installed.
- Then, mark packages that look risky (very old, abandoned, custom forks, dev branches, strange plugins).
- Finally, decide what to update, replace, remove, or isolate.
You do not stop trusting Magento. You do not stop trusting your team.
You just stop trusting the rest of the stack "by default."