Before adding a data pipeline connector, answer ten questions: who wrote it, what code it runs, what access it needs, where its credentials live, how it is versioned, what data it moves, where that data lands, who can change it, how you will see it misbehave, and how you remove it.
Definition
A connector is a component that reads from or writes to an external system for a pipeline: a database source, an API reader, a warehouse loader. It runs with a credential for that system, and it usually runs unattended. That combination is why it deserves review.
The ten questions
- Who maintains it? Official, vendor or community. Airbyte's connector development docs, for example, describe community maintained development kits as not officially supported and to be used with caution. Know which category you are in.
- What kind of connector is it? A declarative one built from configuration has less custom code to review than a connector written in a general purpose language. Airbyte's docs recommend its Connector Builder for most HTTP API sources, with code based kits for more complex cases. Less code is not zero risk, but it is a smaller review.
- What code does it bring with it? Libraries, drivers and transitive dependencies. Generate a bill of materials and scan it.
- What access does it need? Read only where possible. For a database, a dedicated account with narrow grants, as in Debezium replication user least privilege.
- Where do credentials live? Never in the connector config in clear text. See where pipeline secrets go.
- How is it versioned? Exact version, recorded, upgraded by a reviewed change. See what to pin.
- What data does it move? Which tables or fields, and whether personal data is included. Capture only what you need.
- Where does the data land? The destination has its own access rules. A narrow source feeding a broad destination is still a broad exposure.
- How will you notice a problem? Alerts on failures, volume changes and credential errors, and an audit trail of who changed its config.
- How do you remove it? Revoke the credential, delete the config, remove the plugin and delete any slots, queues or staging data it created.
Scoring the answers
You do not need a numeric score. Write one line per question and look for blanks. A blank on questions 3, 4 or 5 is a reason to stop. A blank on 9 or 10 is a reason to schedule the missing work before go live, not after.
Where reviews go wrong
Teams often review the destination and trust the connector because it came from a catalogue. A catalogue listing says the connector exists, not that someone reviewed its dependencies. Others review a connector once and never again, even as versions change. Put the connector's version in the same inventory as every other dependency, and re-scan it when advisories land.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and look for entries you did not choose directly. That is what question three asks you to find in a connector.
Safeguard's SBOM and dependency scanning can do this for connector code, and the free scan at gold.safeguard.sh/scan is a place to start.
Quick check
Is a connector from an official catalogue safe by default?
Not by default. A listing shows availability, not a review of its libraries or the access you give it. Run the same questions.
Which questions are blockers?
Unknown code and dependencies, unclear access scope and unmanaged credentials. Fix those before go live.
Sources
- Connector Development, Airbyte documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
