Dependencies

Dependencies

The platform relies on third-party libraries, as any substantial application does.

Where to find it

Architect Panel → Activity:

• Error Log — where a dependency problem usually surfaces

Architect Panel → Configuration:

• Site Settings — the platform version in use

Why this is your concern

You did not choose these libraries and you are running them. A vulnerability in one is a vulnerability in your installation, and "we use a platform" is not an answer anybody accepts on a security questionnaire.

Know what you are running

Be able to say which platform version you are on and when it was last updated. That single fact answers most dependency questions, because platform updates carry library updates with them.

An installation nobody can date is an installation nobody can assess.

Staying current is the strategy

Rather than tracking individual libraries. The realistic approach for most organisations is to take platform updates on a regular cadence, which brings dependency updates as part of the package.

An installation two years behind is not two years of missing features — it is two years of unapplied fixes, some of them security fixes.

Old is the risk, not new

The instinct is that updating is risky and staying put is safe. The reverse is true over any meaningful period: an update might break something you can test for and fix, and a known vulnerability in an old library is being actively looked for.

Watch what you add yourself

Anything you introduce — a library used by an extension, a script, a vendored component — is yours to track. The platform's update cadence does not cover it, and it will be forgotten precisely because nobody chose it deliberately.

Keep a note of what you have added and where it came from.

Client-side libraries too

Anything vendored into the front end is delivered to your users' browsers. Old client-side libraries are a real attack surface and are easy to overlook because they are not on the server.

Have somebody responsible

"Keeping the platform current" needs an owner, or it is nobody's job and it does not happen. It is a small recurring task and an enormous one-off task if left.

Worked example

An organisation takes platform updates quarterly, records the version and date after each, and keeps a short list of the two libraries its extensions use. When a security questionnaire asked what it ran and how it stayed current, the answer took ten minutes rather than a week.

Recommendations

• Know your version and update date.
• Take updates on a cadence rather than when forced.
• Track anything you added yourself.
• Give it an owner.

Updating Safely

Updates become frightening when they are rare. The way to make them safe is to make them ordinary.

Where to find it

Architect Panel → Integration & Connections:

• Deployments — how a version reaches an environment

Architect Panel → Activity:

• Error Log — the first place a problem appears

The sequence

1. Read what changed, particularly anything flagged as breaking.
2. Apply it somewhere that is not production.
3. Exercise the things your organisation actually depends on.
4. Check the error log there.
5. Apply to production at a time somebody is watching.
6. Check the error log again.

Test what you actually use

Not everything — that is why updates get deferred. Write down the ten things your organisation would notice immediately if they broke, and exercise those.

A short honest list, actually tested, beats an exhaustive plan nobody completes.

Give particular attention to your own code

Extensions, custom fields and anything bespoke are the most likely things to break, because the platform's own tests do not cover them. They are also the things nobody remembers exist.

Keep a list of your customisations and check each after an update.

Be able to go back

Before applying anything: know how to revert, and have a backup you have confirmed exists rather than assumed. The confidence to update comes from being able to undo it.

Schema changes are separate

Database changes are a deliberate step with their own rollback, not something that happens as part of a deployment. Plan them as their own exercise and do not assume an application rollback undoes them.

Update at a sensible time

When people are available to notice and fix a problem. Not at the end of a Friday, not before a holiday, and not immediately before something your organisation depends on.

Small and frequent beats large and rare

A quarterly update is a manageable change with a short list of differences. Two years of updates applied at once is a project with an unknowable failure surface, and the reason organisations end up stranded on old versions.

Check the error log the next morning

Some problems only appear under real use — a scheduled task overnight, a monthly process, an integration that runs at eight. A clean log an hour after updating is not the same as a clean log the next day.

Worked example

An organisation updates quarterly on a Tuesday morning, having tested a written list of twelve things in a non-production environment and checked its three extensions specifically. The error log is reviewed that afternoon and again the next morning, which twice caught a scheduled task failing overnight.

Recommendations

• Keep a short written list of what to test.
• Check your own customisations specifically.
• Confirm the backup before you start.
• Check the log the next morning, not just after.