Ipynb credential check — check your notebook free

Twenty-three findings rode along in the notebook a Berlin fintech data scientist attached to a risk ticket last Tuesday — 18 rules over one six-cell .ipynb, and every finding sat in a saved output rather than in the code. The code was fine. The code was never the problem.

A .ipynb is not source code. It is source code plus a saved copy of everything the code printed. Open one in a text editor and the JSON has two halves: the cells you wrote, and an outputs array holding the stdout, the rendered dataframe, the error value and every line of the traceback from the last time the cell ran. You stop looking at outputs about four seconds after you read the number you wanted. The file keeps them forever.

In the sample notebook shipped with Notebook Share Gate, the first cell dumps os.environ filtered to keys and tokens. The output holds a live sk- API key, an AWS access key id and a GitHub token, in full. The second cell builds a connection string and prints it to confirm the host — password included. The third calls df.head() on three real customers and saves their email addresses, their IBANs and their full card numbers into the file. The fifth fails, and the traceback names a home directory, an internal ML host and a private network address. That is 23 findings: 16 error, 7 warn, 15 distinct rules out of 18.

The cleared version of the same notebook, same analysis, outputs emptied and the PII columns masked, reports 0.

Six classes of leak live in that output blob. Live credentials. Customer identity. Payment data. Internal estate. Employee identity — a traceback path is a person's name. And unreproducible runs, where the execution counts jump from 7 back to 4, meaning the saved numbers were never produced by a top-to-bottom run and the auditor reading them cannot reproduce a single one.

The obvious objection is that a secret scanner already handles this. It does not, and for a structural reason. Scanners and pre-commit hooks read the code in a diff. The notebook keeps what the code printed in a separate JSON array, line-escaped, sometimes base64, and a rule written for a .py file walks straight past it. A chatbot cannot help either: it can only read the file you paste into it, which means pasting the secrets somewhere new.

The clock matters more than the embarrassment. GDPR Art. 33 gives you 72 hours from becoming aware of a personal-data breach to notify the supervisory authority. Art. 83(5) caps the administrative fine for that class of infringement at EUR 20 million or 4 % of total worldwide annual turnover, whichever is higher. A notebook with three customers' IBANs in it, sent to a colleague outside the team, is a disclosure. The awareness clock starts when someone notices — which is usually when someone else notices.

Notebook Share Gate reads the parts a linter does not open: stream text, text/plain and text/html results, evalue, every traceback line, the cell source, and metadata.widgets, where saved widget state keeps values the visible outputs no longer show. Eighteen rules, each reporting the rule name, the severity and the line in the file, so you can jump to it and clear it.

Free, with no key: audit the notebook you have open. That job finishes. The licensed layer moves to a different axis — scope and the record. It sweeps every .ipynb in the workspace in one pass and exports a dated audit record you keep on file, which is the artefact you want before an auditor asks which notebooks touched customer data.

The same engine.js runs in the browser on the free web page. Paste a notebook, get the same findings, nothing uploaded.