Hackathon and demo day security checklist for engineering teams

For hackathons and demo days, use separate accounts and fake data, issue short lived credentials, check every repository before making it public, choose dependencies carefully and clean everything up afterwards. Prototypes written in a rush have a way of reaching production, so give them a safe start.

Before the event

• Create a separate sandbox account or project with a spending cap, and keep it apart from production.
• Provide fake or sanitised data for people to work with. Never hand out a copy of production data because it is convenient.
• Issue short lived credentials that expire when the event ends. Avoid shared passwords.
• Set rules for outside tools. If participants may use AI coding assistants or hosted notebooks, say what data may go into them.
• Decide who owns the results, and what happens to code afterwards.

During the event

1. No secrets in repositories. Use environment variables and a shared sandbox vault. Run a secret scanner on every push, since mistakes are most common when time is short.
2. Think before adding dependencies. Copying an unfamiliar package to finish a demo is an easy way to bring in something harmful. Check the name for typos, the maintainer and recent activity, and prefer well known libraries.
3. Do not expose test servers carelessly. A demo server opened to the internet with default credentials will be found. Restrict access by address or add a password.
4. Be careful with live demos. Do not show real accounts, tokens or private chats on screen. Use a clean browser profile.
5. Treat visitors with care. Public displays and shared Wi Fi are visible to everyone. Do not log into personal accounts on shared machines.

Before making a repository public

Search history for secrets, check licences for copied code, remove private URLs and internal names, and add a short readme that says the code is a prototype and not for production use.

Afterwards

• Revoke every credential issued for the event.
• Delete the sandbox resources and spending allowances.
• Archive winning prototypes in a private repository, and mark them as unreviewed.
• If a project is promoted to production, run it through your normal review: threat model, dependency scan, code review and logging.
• Collect lessons, since they feed the next event.

Safeguard's free scan at gold.safeguard.sh/scan can check a prototype's dependencies before it goes public or further.

If you are a participant and not the organiser, apply the same ideas to yourself. Keep personal and company accounts separate, do not paste work secrets into a team chat, and ask what the event does with your code and data. If your employer has rules on outside work and open source, check them before you start, not after you have a winning idea.

Quick check

Last reviewed: 19 October 2026.