Body
Overview
The Software Development Life Cycle or SDLC standards are designed to streamline software development at the University. These standards support both the security of the development process, and the security of the applications developed. The standard is intended to cover a wide scope of development use cases occurring within the University. As a result, it often leverages product owners' and 'peer reviewers' as authorities to determine the extent of requirements. For example, testing and documentation requirements are going to be specific to the application being developed.
To accomplish this, the guidance was broken up into the following structure:
- Risk classification - Which is used to help understand what standards apply to your application
- Required development practices - Which is the set of requirements to ensure code is developed in a secure way including:
- Practices to ensure applications developed are secure such as credential management, using OWASP proactive controls, and testing
- Practices to ensure applications are deployed in secure manner
- Roles and responsibilities
- Repository requirements - These are the practices requires for a repository to become an approved repository and include:
- Security scanning and reporting requirements
- Hardening requirements of the repository
- Public repositories - These are the requirements for creating and maintaining public repositories
How do I meet the standards?
There are three general strategies for meeting these standards:
- Have OIT develop your application - This is the easiest method as OIT reviews their development practices against these standards and it is our responsibility to meet our own standards.
- Use OIT provided development tools - This is the next easiest method as you will be responsible for correctly using tools, but the tools themselves are reviewed against the standards and there will be documentation and support available to assist with implementing these.
- Learn and implement the standards yourself - This is the hardest, but most flexible method as you will be responsible for implementing the standards into your own existing development practices. OIT is happy to assist with reviewing and providing suggestions and support to better meet the standards.
FAQ
What about AI developed code?
Regardless of the level of involved AI was in the development of the code (assisted, reviewed, or full generated), it must still be secure code and therefore must still follow the standards. Additionally, to ensure applications are supportable in the long term, the applications must be reviewed and understood. However, given the wide scope of the document, the determination of how much it must be reviewed and understood is at the discretion of the product owner, since they will be held accountable if something needs to be fixed, and the reviewer, since they need to ensure the code is functional.
When do I need a peer reviewer?
While a peer review is always recommended to ensure the quality of code, it is only needed for moderate and high risk applications. The level of detail those code reviews is left intentionally vague to allow for product owners and peer reviews to use their judgement on what is appropriate for their application.
Can I use AI to do my peer review?
While an AI analysis tool does not count as peer reviewer, a human peer reviewer may use it to assist with their review. For low risk applications where a peer reviewer is not required, using AI to perform a 2nd system analysis can assist with quality management.
Where can I store my code and containers?
Approved code and container repositories can be
found here.
What if something is vague or undefined?
While reading this document some requirements may have open ended wording such as use of the term periodic. In general, the open ended wording is to allow system owners flexibility in determining their own requirements, such as determining if periodic means monthly or yearly for their system. OIT Security may request the reasoning of specific implementation of the controls. Additionally, OIT Security may require specific changes to the implementation should the reasoning be insufficient.