Take JDBC driver jars from your database vendor or a reviewed internal repository, pin the version, and record the file hash. Spark only requires the jar on the classpath, so it will load whatever you put there. Keep passwords out of the URL and out of code, even though the docs show plain examples.
What Spark requires
The Spark JDBC guide says to include the JDBC driver for your database on the Spark classpath. Its example passes a driver jar to both the driver class path option and the jars option in spark-shell. Nothing in the page describes verifying that jar. Spark loads the class named in the driver option and uses it.
A JDBC driver is code that runs inside your executors and handles your credentials and your rows. It deserves the same scrutiny as any library.
Where drivers usually come from
- A manual download from a vendor site, copied to a shared folder.
- A Maven coordinate pulled through the packages option, which resolves transitive dependencies too.
- A jar baked into a custom image.
- A file left on a cluster years ago that nobody can trace.
The last one is the common problem. The jar has no owner, no version record and no scan.
A sourcing checklist
- Pick one source of truth, such as an internal artifact repository.
- Download from the vendor's official location and verify the checksum or signature if the vendor publishes one.
- Record the version, source URL and SHA256 in the repository next to the job.
- Reference the artifact by exact version. Avoid floating ranges.
- Scan the jar. Drivers bundle their own libraries, so a scanner should read inside the jar.
- Replace ad hoc copies on shared storage with the controlled one.
Where passwords go
The Spark docs show user and password as connection properties or options, and show that connection properties may be specified in the URL, with an example that puts the password in the URL text. That example is convenient and risky: URLs end up in logs, error messages and query history.
Better habits:
- Read credentials from your secret store at job start and pass them as options at run time.
- Never embed a password in a URL string.
- For Kerberos, the docs say the keytab must be uploaded to all nodes, and that keytab authentication is not always supported by the driver. Test your driver.
- Remember that redaction settings in Spark match patterns and can miss things, so do not rely on them to hide a secret you should not have logged.
Using the packages option
If you pull the driver with the packages option, the Spark docs say all transitive dependencies are handled. That is convenient, and it also means the job downloads code at submit time. See the post on what the packages option downloads for the details.
Safeguard's SBOM and dependency scanning can read jars and manifests to list drivers and their bundled libraries, and its policies can flag unreviewed versions. The free scan at https://gold.safeguard.sh/scan is a quick way to try it.
Quick check
Does Spark verify the JDBC jar I supply?
The JDBC guide does not describe any verification. It only requires the jar on the classpath, so you need your own checks.
Is it fine to put the password in the JDBC URL for a test?
It works, but URLs get logged. Use options from a secret store even in tests so the habit carries over.
Sources
Last reviewed: 19 October 2026.
