Run security office hours as a fixed, short, drop in slot where developers bring real work: a finding they do not understand, a design they are unsure about, a dependency choice. Keep it regular, keep it friendly, record answers publicly afterwards, and measure whether questions arrive earlier in the build.
Why offer them
Developers often avoid asking the security team for help because the request feels like admitting a mistake or opening a ticket. A standing slot lowers the cost of asking. It also gives the security team a steady view of what developers are confused about, which is better input for training and tooling than any survey.
Pick a format
| Format | Good for | Watch out for |
|---|---|---|
| Weekly 45 minute video drop in | Most teams | Empty room in the first month |
| Chat channel with a daily window | Distributed teams | Answers get buried |
| Embedded hour in a team's standup | A team with a big launch | Does not scale |
| Pair review of a pull request | Hard design questions | Needs prior booking |
Start with one weekly slot at a time that does not clash with sprint ceremonies. Late morning midweek tends to work better than Monday or Friday.
A simple agenda
- Five minutes: one tip or recent change, such as a rule you tuned.
- Thirty minutes: open questions, first come first served.
- Ten minutes: write down answers that others will want.
Do not turn it into a lecture. If nobody has questions, offer to look at a random recent pull request together.
Who should staff it
Two people is ideal: someone from the security team and a security champion from an engineering team. The champion speaks the developers' language and can say how a fix would actually fit the codebase. Rotate the champion so no one burns out.
Make it worth coming to
- Answer in plain words and show the fix on screen
- Never ask whether someone "should have known"
- Follow up in writing within a day
- Turn repeated questions into a short how-to page or a better rule message
- Say thank you, publicly, for good questions
Publish what you learn
Keep a running question log. Group questions by theme every month: secrets, dependency upgrades, authentication, input handling, tool messages. If one theme dominates, fix the cause, whether that is a clearer finding message, a library recommendation or a short training session.
How to tell if it works
Count attendance, but pay more attention to what changes:
- Do questions arrive before merge rather than after an incident?
- Do repeated questions get rarer once a how-to exists?
- Do developers from more teams show up over time?
- Does the number of overrides and exceptions fall?
A low turnout is a signal to change the time, the name or the promotion, not to cancel it quietly.
Quick check
How often should security office hours run?
Weekly is a good start because it builds a habit. Move to fortnightly only if the questions dry up for several weeks.
What if nobody comes?
Ask a few developers what would make it useful, move the time, and bring your own examples from recent pull requests. A new slot usually takes a month to catch on.
Safeguard's free scan at gold.safeguard.sh/scan gives developers something concrete to bring: a real result on their own repository.
Last reviewed: 19 October 2026.
