feat(instructions): Secure by design

[andrwca]

Instruction File Name

secure-by-design.instructions.md

Scope

Workspace-level (applies to entire repository)

Purpose

Our current project requires adherence to secure-by-design principals, specifically, the ones listed here. https://www.security.gov.uk/policy-and-guidance/secure-by-design/

It would be good to have instructions which can embody the requirements of secure-by-design, so that code implementations suggested by the agent will reference or otherwise assess adherence to the principals.

I'm currently playing around with my own instructions for secure-by-design, so if this might be of use, let me know and I'll make a PR.

Requirements

Secure by design principals: https://www.security.gov.uk/policy-and-guidance/secure-by-design/

[andrwca]

I see this has been added to the milestone, so I'll do some more testing on what I've got currently and put in a PR in the next couple of weeks. (I'm OOF this week.)

[WilliamBerryiii]

Thank you for raising this, @andrwca. Secure-by-design guidance is an important capability for the project. After reviewing the existing security work and our artifact architecture, we think this is a strong candidate for an on-demand skill rather than an always-loaded instructions file.

Why a skill instead of instructions

An instructions file with applyTo: "**" injects its full content into every Copilot interaction, consuming context window budget whether or not the session involves security work. For a topic as comprehensive as secure-by-design (covering OWASP Top 10, threat modeling, secure defaults, input validation, and more), that overhead adds up quickly and can crowd out task-relevant context.

PR #408 discovered this exact problem during the Security Champion work. The initial implementation used workspace-level instruction files for OWASP guidance, but had to restructure into an on-demand skill with dedicated reference documents so the content loads only when explicitly needed. That pattern keeps security guidance available without penalizing every interaction.

A skill gives us:

• On-demand loading — content activates only when the user or agent invokes it
• Self-contained packaging — scripts, reference docs, and the SKILL.md live together
• Cross-platform support — bash and PowerShell scripts per contribution requirements
• Collection membership — discoverable through the security-planning collection

Related work to consolidate with

• feat(agents): Add Security Champion agent with SDL and OWASP guidance #416 — Security Champion agent (actively being developed in PR feat(agents): add Security Champion agent with SDL and OWASP guidance #408, already adopted the skill pattern)
• feat(agents): Security Auditor to track and do gap analysis on security plans and updates #336 — Security Auditor agent (related security tooling)

We recommend aligning this issue's scope with #416 so the secure-by-design guidance becomes part of (or a companion to) the Security Champion skill rather than a separate artifact. This avoids fragmentation across multiple security instruction files.

AI artifact contribution requirements

For anyone picking this up as a skill, the relevant contribution guides are:

• Skills contribution guide — file structure (.github/skills/<name>/), SKILL.md format, script requirements
• Common AI artifact standards — collection manifests, maturity levels, dependency declarations, attribution
• Instructions contribution guide — for reference on the applyTo scoping mechanics and why narrow globs are preferred over "**"

[obrocki]

Thank you for raising this, @andrwca. Secure-by-design guidance is an important capability for the project. After reviewing the existing security work and our artifact architecture, we think this is a strong candidate for an on-demand skill rather than an always-loaded instructions file.

Why a skill instead of instructions

An instructions file with applyTo: "**" injects its full content into every Copilot interaction, consuming context window budget whether or not the session involves security work. For a topic as comprehensive as secure-by-design (covering OWASP Top 10, threat modeling, secure defaults, input validation, and more), that overhead adds up quickly and can crowd out task-relevant context.

PR #408 discovered this exact problem during the Security Champion work. The initial implementation used workspace-level instruction files for OWASP guidance, but had to restructure into an on-demand skill with dedicated reference documents so the content loads only when explicitly needed. That pattern keeps security guidance available without penalizing every interaction.

A skill gives us:

• On-demand loading — content activates only when the user or agent invokes it
• Self-contained packaging — scripts, reference docs, and the SKILL.md live together
• Cross-platform support — bash and PowerShell scripts per contribution requirements
• Collection membership — discoverable through the security-planning collection

Related work to consolidate with

• feat(agents): Add Security Champion agent with SDL and OWASP guidance #416 — Security Champion agent (actively being developed in PR Adds Security Champion skills / chat / agent mode to provide comprehensive security guidance by integrating Microsoft's Security Development Lifecycle (SDL) practices alongside existing OWASP frameworks. #408, already adopted the skill pattern)
• feat(agents): Security Auditor to track and do gap analysis on security plans and updates #336 — Security Auditor agent (related security tooling)

We recommend aligning this issue's scope with #416 so the secure-by-design guidance becomes part of (or a companion to) the Security Champion skill rather than a separate artifact. This avoids fragmentation across multiple security instruction files.

AI artifact contribution requirements

For anyone picking this up as a skill, the relevant contribution guides are:

• Skills contribution guide — file structure (.github/skills/<name>/), SKILL.md format, script requirements
• Common AI artifact standards — collection manifests, maturity levels, dependency declarations, attribution
• Instructions contribution guide — for reference on the applyTo scoping mechanics and why narrow globs are preferred over "**"

Happy to incorporte bits and pieces that make sense into my PR, too!

[JasonTheDeveloper]

Something else you might want to consider including as part of the instructions: https://www.cyber.gov.au/business-government/secure-design/secure-by-design

I'm sure there's some overlap between this one and the one mentioned above. Could ask copilot to take the best of both and include it in the instruction.