Skip to content

Security

Developers working on CSE projects should adhere to industry-recommended standard practices for secure design and implementation of code. For the purposes of our customers, this means our engineers should understand the OWASP Top 10 Web Application Security Risks, as well as how to mitigate as many of them as possible, using the resources below.

If you are looking for a fast way to get started evaluating your application or design, check out the "Secure Coding Practices Quick Reference" document below, which contains an itemized checklist of high-level concepts you can validate are being done properly. This checklist covers many common errors associated with the OWASP Top 10 list linked above, and should be the minimum amount of effort being put into security.

Requesting Security Reviews

When requesting a security review for your application, please make sure you have familiarized yourself with the Rules of Engagement. This will help you to prepare the application for testing, as well as understand the scope limits of the test.

Quick References

Azure DevOps Security

DevSecOps

Introduce security to your project at early stages. The DevSecOps section covers security practices, automation, tools and frameworks as part of the application CI.

OWASP Cheat Sheets

Note: OWASP is considered to be the gold-standard in computer security information. OWASP maintains an extensive series of cheat sheets which cover all the OWASP Top 10 and more. Below, many of the more relevant cheat sheets have been summarized. To view all the cheat sheets, check out their Cheat Sheet Index.

Check out the list of tools to help enable security in your projects.

Note: Although some tools are agnostic, the below list is geared towards Cloud Native security, with a focus on Kubernetes.

  • Runtime Security

    • Falco
    • Tracee
    • Kubelinter
      • May not fully qualify as runtime security, but helps ensure you're enabling best practices.
  • Binary Authorization

    Binary authorization can happen both at the docker registry layer, and runtime (ie: via a K8s admission controller). The authorization check ensures that the image is signed by a trusted authority. This can occur for both (pre-approved) 3rd party images, and internal images. Taking this a step further the signing should occur only on images where all code has been reviewed and approved. Binary authorization can both reduce the impact of damage from a compromised hosting environment, and the damage from malicious insiders.


Last update: July 9, 2021