Why a compliance certificate is not the answer to “is it secure?”

Certifications are necessary and they are not sufficient. They attest that controls existed at the time of assessment. They tell you nothing about what happens between assessments — which is where software actually changes.

The question worth asking a vendor is narrower and harder to answer with a logo: what happens to a line of code between a developer writing it and it running against my customers’ identity documents? A vendor with a real answer will describe a sequence. A vendor without one will describe a certificate.

What the sequence looks like

The pipeline DSS built for its own delivery, and then extended into UniCredit Bulbank’s infrastructure, runs in this order:

1. Dependency auditing and testing. Before anything is built, dependencies are audited and tests run inside an internal Kubernetes environment. Supply chain risk is checked first because it is the cheapest place to catch it.
2. Static code analysis with SonarQube. Every change is scanned for bugs, vulnerabilities and code smells against enforced quality gates. Code that fails does not proceed.
3. Docker image build. The application and its dependencies are packaged into an immutable artefact, which is what makes the following steps meaningful — you are scanning and deploying the same object, not a rebuild of it.
4. Vulnerability scanning with Trivy. The built image is scanned for known CVEs before it goes anywhere. This catches vulnerabilities in the base image and transitive dependencies that source-level analysis does not see.
5. Deployment via Helm charts to Kubernetes. Deployment is declarative and reproducible rather than scripted and improvised, which means a rollback is a version change rather than a recovery operation.
6. Orchestration through Jenkins, running Kubernetes pods as build agents so the whole chain executes automatically and identically on every change.

What changes when the institution runs it too

This is the part that distinguishes a vendor relationship from a real integration with a regulated institution.

In the UniCredit Bulbank arrangement, a commit to a designated branch triggers a Jenkins job that commits to UniCredit’s own repository. UniCredit’s Jenkins instance then mirrors the entire pipeline — the same dependency auditing, the same tests, the same SonarQube analysis, the same Docker build, the same Trivy vulnerability scan, the same push to an image repository — inside their infrastructure, under their control. The final step diverges: their Jenkins deploys to their OpenShift environment rather than to ours.

Two properties follow from this, and both are things a bank’s security function will ask about directly.

The institution independently verifies rather than trusting. UniCredit does not accept a vendor’s assertion that a build passed its checks. Their own instance runs the checks. A vendor pipeline that produced a clean result and a bank pipeline that did not would be visible immediately.

The institution retains deployment control. Code enters their environment through their pipeline into their infrastructure. No vendor process reaches into a production banking environment.

Who can see what is happening?

All logs from the deployment process are available in UniCredit’s own Grafana instance, for real-time monitoring and troubleshooting by their teams.

This sounds like a small operational detail. It is not. Observability that lives only in the vendor’s stack means the institution’s engineers are dependent on the vendor to answer questions about their own environment — during incidents, when the vendor’s response time becomes the institution’s outage duration. Logs in the institution’s monitoring stack means their on-call engineer can diagnose without opening a ticket.

When evaluating a verification vendor, ask specifically: where do the logs land, and can my team query them without asking you?

Why the same pipeline runs in every environment

The same deployment process is used for internal development and testing environments and for UniCredit’s test and production environments. No shortened path for lower environments, no expedited route for urgent releases.

This is the control most often quietly abandoned under delivery pressure, and abandoning it is how environment drift begins. Once staging and production diverge, testing in staging stops predicting production behaviour, and every deployment carries risk that nobody can quantify. For an identity verification system, the specific danger is concrete: a configuration difference between environments means the verification logic you tested is not the verification logic making decisions about real customers.

Questions worth asking any identity verification vendor

Adapted from what a financial institution’s security review actually covers:

• What runs between commit and production, in order? Expect a sequence with named tools. Vagueness here is the answer.
• Are dependencies audited, and container images scanned, on every build? Source-level static analysis alone leaves base-image vulnerabilities unexamined.
• Can our team run the same pipeline in our infrastructure? Relevant for institutions that require deployment control. Not every buyer needs this; every buyer should know whether it is possible.
• Where do deployment and application logs land? Vendor-only observability is a dependency, and it becomes visible at the worst possible moment.
• Is the process identical across environments? If there is a faster path for hotfixes, that path is where an unreviewed change reaches production.
• What is the rollback procedure, and when was it last exercised? Declarative deployment makes rollback a version change. Scripted deployment makes it an improvisation.

Frequently asked questions

How do I choose an identity verification provider for a high-security environment?

Ask what runs between a commit and production, in order, with named tools. A vendor with a real answer describes a sequence: dependency auditing, static analysis, artefact build, vulnerability scanning of the built image, declarative deployment. A vendor without one describes a certificate.

Is a compliance certificate enough to assess a vendor’s security?

No. Certifications attest that controls existed at the time of assessment. They say nothing about what happens between assessments, which is when software actually changes. The useful question is what happens to a line of code between a developer writing it and it running against customer identity documents.

Can a financial institution run the vendor’s deployment pipeline itself?

It is possible and some institutions require it. In the arrangement DSS built with UniCredit Bulbank, a commit triggers a job into the bank’s own repository, and the bank’s Jenkins mirrors the full pipeline — dependency auditing, tests, SonarQube analysis, Docker build, Trivy scanning — before deploying to their OpenShift infrastructure. The bank verifies independently rather than trusting an assertion.

Where should deployment logs be visible?

In the institution’s own monitoring stack, not only the vendor’s. In the UniCredit Bulbank implementation all deployment logs are available in the bank’s Grafana instance. Observability that lives only with the vendor means the vendor’s response time becomes the institution’s outage duration during an incident.

Why does identity verification need stricter security than other software?

Because the data cannot be reissued. A breach exposing government identity documents and biometric data is not a password reset — identity documents cannot be rotated, and neither can a face. The cost of failure is not recoverable by the customer, which changes the standard of scrutiny that is reasonable.