Singapore coding sessions: choose a safe channel for a security-related contribution

The problem

A Singapore contributor thinks a bug may have security implications and wants workshop help, but posting the real example publicly could disclose information before the project has assessed it.

Read the reporting rule before the issue form

A repository's ordinary bug process may differ from its security process. FormSG's contribution instructions direct ongoing security bugs away from public issues to a maintainer channel. Check the rules of the actual project concerned before sharing details. A coding event's public chat or shared document should not be treated as a private reporting route. Identify the named project, the actual instruction and the recipient role before deciding where the observation belongs. A public contribution issue and a designated reporting route can serve different purposes even when both concern a bug. A workshop facilitator may explain that distinction without being the project’s responsible recipient. Keep an unknown route as a missing condition and locate the official instruction; do not ask an open room to examine the live material just because the process is unclear. A public repository, an event place or access to a system does not itself decide what you may disclose.

• FormSG/CONTRIBUTING.md at develop · opengovsg/FormSG · GitHub ↗ · Source checked 20 October 2026

Make two records with different purposes

Use a private observation note for material the actual reporting route requests, within the permissions you already have. Keep the task and setup, expected behaviour, observation actually obtained and reason for concern separate from an asserted impact. For public learning, prepare a different card: general process question; wholly invented example if useful; information intentionally excluded; actual session activity; and condition still unresolved. Do not create the public card by merely deleting a name from the private note. An account relation, trace or combination of details can remain specific to the original situation. The two records need not contain the same material to serve their different questions.

Keep the possible finding out of the public example

For a workshop question, create an unrelated toy scenario that explains the general concept without reproducing a live target, account, token or access path. Ask about the reporting process or the type of evidence maintainers need. If making the example safe would remove the essential detail, keep that discussion for the designated project channel instead. State what the invented scenario is meant to illustrate and what it cannot establish. You could ask how a project separates ordinary issue discussion from a report that may need its designated channel, without reproducing the behaviour of a real target. An invented exercise supplies no finding about that target. If the concept cannot be explained without disclosing the sensitive relationship or access path, retain the limit and ask a process-only question. Do not call a replacement anonymous, approved or equivalent to the original simply because you made it shorter. The actual handling and disclosure conditions still govern the real material.

Complete a fictional public-question choice

All people, project arrangements and replies in this example are invented. A contributor has a possible concern from work they were permitted to observe, but the workshop offers a group discussion of reporting processes. They prepare a question asking who receives a possible finding under the project’s stated process, with no real account, log, target or reproduction steps attached. A fictional host accepts that process question and asks whether the contributor can also display the original log to the room. The contributor does not supply it: permission for the process question says nothing about sharing the log or the host’s assessment role. The completed decision is to keep the public discussion at its accepted process scope and locate the project’s designated route for the separate observation.

Collect a restrained private observation

Record what you observed, the expected behaviour and the context needed to understand it, within the authority you already have. Do not expand testing against other accounts or services to make the report more impressive. Keep factual observation separate from your interpretation of its impact. Use the project's reporting instructions to decide what to include and where. Keep the source of the observation and its limit visible. An unexpected display can be an observed difference while its cause, intended access rule or security significance remains unknown. Do not invent impact, inspect another person’s records or extend an exercise to a live service to settle that uncertainty. Follow the responsible project’s instructions for the appropriate report and any requested next step. An authorised environment for one workshop task is not permission for a different target or broader investigation. This guide helps prepare the channel and question; it does not assess a vulnerability, supply testing permission or prescribe an incident response.

Read the actual response at its stated stage

Continue the wholly fictional record. The contributor follows the identified project route with the material allowed by its instructions. The recipient replies that the report was received and asks for clarification of the already observed state. Record receipt and the requested clarification; assessment, impact and any repair remain unresolved. An enquiry acknowledgement is not confirmation of a vulnerability or an instruction to explore other accounts. If no response arrives, retain the unknown status and follow the stated process rather than moving the material into a public event chat. A later permitted correction or decision belongs to its own record, with its actual scope.

Choose a learning session for the right purpose

A secure-development session can explain how teams triage reports without validating your particular finding. Check whether the programme covers contribution process, defensive practices or practical exercises, and prepare the safe question accordingly. Do not promise a demonstration of a live weakness. Any eventual fix, disclosure or acceptance follows the responsible project's process, not a workshop attendance milestone. Ask whether the selected programme offers explanation, supplied practice or discussion of a participant’s process question. The CTF-versus-defensive-exercise guide develops the actual learning format; the lab-readiness guide develops setup and permission for the named exercise. Neither turns an event into the live project’s reporting channel. An unsent organiser enquiry could say, “I want to discuss how contribution and sensitive-reporting routes differ, using only a general process question. Does this session include that activity, and what public material arrangement applies?” Keep an offer to teach or discuss separate from permission to handle the original finding. You can learn from the session while the project assessment remains pending.

Keep the learning result separate from the project finding

After the permitted discussion, record the process clarified, the material actually used and the question still outside the session. In the fictional case, the contributor understands the two routes and has a receipt through the designated one; the group has not assessed the underlying observation or confirmed a fix. Keep that limited result rather than describing the workshop as vulnerability validation. Preserve the real report’s status through its actual instructions, and avoid attaching private evidence to a public contribution summary. Use Boardzip’s free contribution search for the learning activity you need, then check its format and admission. Search access, a host’s interest and workshop attendance do not create disclosure authority or an accepted security contribution.