Secure Vibe Coding with GitHub Copilot, C# and .NET

Prepare the development environment needed for the course. This section confirms the .NET SDK, development IDE, terminal access, and build workflow so learners can follow the hands-on lessons without setup friction.

Show learners how to verify their .NET installation.

• Install or confirm .NET 10 SDK

• Run dotnet --info

• Verify available SDKs

• Confirm terminal access

Set up the editor environment for the course.

1. Open the workspace in Visual Studio or VS Code

2. Confirm C# extension support

3. Confirm terminal integration

4. Confirm restore/build workflow

Review the completed environment setup and confirm that the learner can run .NET commands, open the project in an IDE, and use the terminal to restore, build, and test the application.

Explain vibe coding in practical developer terms.

Key points:

• Vibe coding uses AI to rapidly generate code, features, tests, and fixes.

• The developer describes intent and the AI suggests implementation.

• This can be powerful for speed and experimentation.

• It can also create risks when developers accept generated code without review.

Define vibe coding as an AI-assisted development workflow where developers describe intent and use AI tools to generate code, tests, fixes, and project structure. This lesson explains the productivity benefit while setting the expectation that generated code must always be reviewed.

Explain the common failure modes of AI-generated code before focusing specifically on security.

Key points:

• AI can generate code that compiles but is not correct.

• AI can misunderstand business rules.

• AI can invent APIs, patterns, or assumptions.

• AI can produce inconsistent architecture.

• AI may generate code that lacks tests, validation, logging, or maintainability.

• AI output often reflects the quality of the prompt and surrounding code.

Explain why developers remain responsible for design, judgment, and verification.

Key points:

• AI can assist, but it cannot own accountability.

• Developers understand business context, user impact, and production risk.

• Human review is needed for correctness, security, performance, maintainability, and compliance.

• The safest workflow is AI-assisted, not AI-abandoned.

• Human-in-the-loop review turns AI into a productivity tool rather than an unchecked risk.

Introduce the repeatable workflow used throughout the course.

Workflow:

• Plan the feature

• Prompt with security constraints

• Generate code in small units

• Review the output

• Refactor unsafe patterns

• Test important assumptions

• Scan before merge or deployment

• Document the final decision

Review the main idea of secure vibe coding.

Key takeaways:

• AI can accelerate development, but it must not replace developer judgment.

• Human review is essential.

• The rest of the course applies a repeatable secure review workflow.

Introduce the planning phase of AI-assisted development. This section shows why secure vibe coding should begin with a clear plan before generating code, especially when the application will handle user data, business rules, and security-sensitive workflows.

Explain why developers should define the project scope, architecture, data model, security assumptions, and success criteria before asking AI to generate code. A stronger plan leads to safer, more consistent AI output.

Use an AI assistant to produce an initial plan for the TaskFlow Lite application. The goal is to define the solution structure, major features, data entities, and security considerations before generating the first version of the codebase.

Review the AI-generated project plan for accuracy, missing requirements, unclear assumptions, and potential security gaps. Learners practice treating AI output as a draft that must be checked before implementation begins.

Use the reviewed plan to generate the initial TaskFlow Lite solution. This lesson demonstrates how to move from planning to implementation while keeping the generated code small enough to inspect, build, and stabilize.

Review the planning and baseline generation workflow. Reinforce that AI-assisted development is safer when the developer plans first, reviews the output, stabilizes the project, and creates a checkpoint before moving forward.

Introduce the core security concepts that guide the rest of the course. This section connects secure coding fundamentals, OWASP guidance, AI-assisted development risks, and threat modeling to the TaskFlow Lite application.

Explain core application security concepts.

Key points:

• Confidentiality

• Integrity

• Availability

• Trust boundaries

• Attack surface

• Secure by design

• Secure by default

• Least privilege

Explain OWASP in a practical way.

Key points:

• OWASP Top 10 as a guide to common risks

• Broken access control

• Injection

• Identification and authentication failures

• Security misconfiguration

• Vulnerable and outdated components

• Software and data integrity failures

Key points:

• Traditional app security risks still apply.

• AI-assisted coding can make those risks appear faster.

• AI-powered apps introduce additional risks, including prompt injection, excessive agency, sensitive data exposure, and unsafe tool use.

• This course focuses on securing apps built with AI assistance, not deep LLM application security.

Key questions:

• What are we building?

• What data does it touch?

• Who should access it?

• What could go wrong?

• What should the AI not assume?

• What checks must be in place before code is accepted?

Activity:
Complete a feature threat card before generating a new endpoint.

Learners classify generated-code mistakes by security category.

Examples:

• Concatenated SQL

• Missing ownership check

• Hardcoded API key

• Overbroad admin endpoint

• Verbose production error

Summarize the security foundation.

In this section, we review how access control failures appear in AI-generated APIs and why working endpoints are not automatically safe endpoints. We will focus on request details, ownership checks, user context, and the risk of exposing records simply because a caller knows an ID.

Learn how broken access control appears in generated code, especially when endpoints retrieve records by ID without verifying whether the caller is allowed to see them. We will connect this risk to OWASP Top 10 guidance and review why server-side authorization must always protect sensitive data.

Prompt the AI assistant to propose a practical access-control plan before changing code. The plan should define who can view a request, how unauthorized access should be handled, and which tests are needed to verify the behavior.

Update the request details flow so records are not returned solely because the caller knows the request ID. Apply server-side access checks, preserve safe response shapes, and avoid leaking unnecessary implementation or user data.

Compare the AI-generated review with your own manual security review. Identify where the AI helped, where it missed context, and why the developer remains responsible for final security decisions.

Ask: Can a normal user enumerate other users’ work?

https://github.com/trevoirwilliams/TaskFlowLite.Secure.VibeCoding/tree/broken-access-hardening

Review the access-control hardening workflow and reinforce the key lesson: a feature can work correctly from a functional standpoint and still fail security review if it does not enforce authorization at the server.

In this section, we review user-controlled input in query strings, filters, and search features. The focus is on validating input, avoiding unsafe query patterns, and ensuring list/search results do not expose data outside the caller’s allowed scope.

Learn how validation applies to AI-generated code. We will distinguish between syntactic validation, semantic validation, and security-focused validation, then review how small input-handling mistakes can lead to larger application risks.

Key points:

• All input crossing a trust boundary must be validated.

• Syntactic validation checks format.

• Semantic validation checks business meaning.

• Allow list validation is safer than block list validation.

• Model constraints and DTOs help enforce expectations.

• Sanitization and encoding serve different purposes.

Prompt for term, but require a plan first: max length, trim whitespace, minimum length if needed, no raw SQL, no string-built commands, user-scoped results.

Apply user scoping before search/filtering. Ensure normal users only see requested/assigned items. Admin behavior should only be taught if the role model exists in code; otherwise, state it as a future production enhancement.

This section focuses on authorization decisions for operations that change application state. We will review update, assignment, and status-change endpoints, then harden them so users can only perform actions that match the business rules.

Clarify the difference between knowing who the caller is and deciding what the caller is allowed to do. We will also discuss why local header-based user simulation is useful for development but should not be treated as production authentication.

Review the application's temporary current-user mechanism and identify its risks. We will discuss caller-controlled headers, unsafe default users, and how production systems should rely on a trusted identity from authentication middleware.

Learn why write operations require stricter review than simple read operations. A flawed update, assignment, or status-change endpoint can corrupt workflow state, bypass business rules, or allow unauthorized users to alter records.

Apply server-side authorization and workflow rules to state-changing operations. Ensure that assignments, updates, and status transitions are allowed only when the current user and request state meet the required conditions.

Summarize how authorization and business rules work together. Reinforce that AI can suggest implementation details, but developers must define and verify the rules that protect application integrity.

This section reviews configuration, secrets, package dependencies, and supply chain risk in AI-assisted development. We will focus on safe local configuration, avoiding the exposure of secrets, reviewing packages, and documenting dependency decisions.

Teach safer secret handling.

Key points:

• Secrets include connection strings, API keys, tokens, certificates, and credentials.

• Secrets should not be hardcoded.

• Secrets should not be committed to source control.

• Logs and errors should not expose secrets.

• Local development and production configuration should be separated.

Use AI to review configuration patterns safely without pasting real secret values. The goal is to get useful feedback on structure, naming, and risk while protecting sensitive information.

Explain dependency and supply chain basics.

Key points:

• AI may suggest outdated or unnecessary packages.

• Direct and transitive dependencies can introduce vulnerabilities.

• Package trust signals matter.

• Dependency alerts should be reviewed and triaged.

• Reproducible builds and lock files can support safer dependency management.

Review the project’s package dependencies and determine whether each one is necessary, current, and appropriate. Learners consider why the package exists, what risk it introduces, and whether an AI-suggested dependency should be accepted.

Review the main practices for protecting secrets and managing dependency risk. Reinforce that AI can help identify patterns, but developers must protect sensitive values and approve package decisions deliberately.

Introduce security-focused testing and automated review checks. This section shows how to verify important security assumptions with tests, build checks, dependency checks, and a repeatable review workflow.

Explain which behaviors should be tested before accepting AI-generated code. Learners focus on authorization, input validation, state changes, error handling, data exposure, and abuse cases rather than only happy-path functionality.

Use AI to generate candidate tests for security-sensitive behavior. Learners review the generated tests to ensure they prove the right assumptions instead of merely increasing test count.

Review AI-generated tests for weak assertions, missing negative cases, overfitted implementation details, and false confidence. Learners practice improving tests so they actually protect security behavior.

Review how security-focused tests and automated checks support safer AI-assisted development. Reinforce that every meaningful checkpoint should be backed by evidence, not just by visual inspection or AI reassurance.