1. Secure by Default
Validate that the product is secure in its default configuration. For this, install the product and configure the product with the default settings. Then perform the appropriate security penetration tests to verify the product is as secure as possible. Afterwards, un-pup the site (either the solution site or the CSharp site) with the default settings, and again perform the security penetration tests to verify the site and its components are as secure as possible. Lastly, configure the SQL roles and user accounts with the security configuration wizard and validate that the product is fully locked down. This step needs to be performed on a single box configuration as well as the secure deployment.
2. Secure by Design
Validate that the product design indeed incorporated security-best practices. Verify that the thread model was adhered to religiously throughout the product life-cycle, and the principle of least privilege and separation of privilege is followed throughout the product.
3. Secure in Deployment
Verify that in deployment, the product can be kept secure, and that the appropriate tools and measures are in place for the customer to diagnose and audit security related issues.
4. Frequency of Security Testing
Perform the security penetration test cases once on a single-box configuration (for both the default configuration and a locked-down configuration) for at least one sprint. For subsequent sprints you can use different configurations
5. Reporting
Threats and vulnerabilities should be logged as bugs. Any security threats that can cause a crash will should be investigated immediately. By most accounts, elevation of privilege is a lot more important than a crash. Anonymous attacks are more important than authenticated ones, and remote attacks trump local ones. So, remote unauthenticated elevation of privilege should be #1 concern. Local authenticated crash is always the lowest on the totem pole. This way you will need to prioritize the attacks.