SANS Site Network
- Current Site
- Training
- Choose a different site Help
- Certification
- Cyber Security Graduate School
- Internet Storm Center
- Security Awareness Training
- Computer Forensics
- Penetration Testing
- IT Audit
- Software Security

Secure Access / Login

Find Training
- Search For Training
- Upcoming Events
- Course List
- NetWars
- Ways To Train
- Training Curricula »
  - Security
  - Management
  - Forensics
  - Secure Software Development
  - Penetration Testing
  - System Administration
  - Incident Handling
  - Intrusion Analysis
  - Audit
  - Legal
  - Cyber Guardian
- Group Discounts
- Calendars
Live Training
- Search For Training
- Upcoming Events
- Summits
- Community Events
- Mentor
- OnSite
- Work Study
- COINS
Online Training
- Search For Training
- vLive
- OnDemand
- Simulcast »
  - Event
  - Custom
- Security Awareness
- SelfStudy
Programs
- Voucher Credit
- Cyber Guardian
- Cyber Ranges
- Hacker Guard
- Cybersecurity Innovation Awards
- Enterprise Solutions
- DoD 8570
Resources
- Reading Room
- Webcasts
- Newsletters
- Blogs
- Top 25 Programming Errors
- Top 20 Critical Controls
- Security Policy Project
- From Vendors
- Additional Resources
Vendor
- Overview
- Sponsorship
- Demographics
- Events
- Contact
About
- About SANS
- Why SANS?
- Instructors
- Contact SANS
- SANS FAQ
- Link to SANS
- Press Room
- PGP Key
- PGP Key - Local Copy

Application Security Procurement Language

Introduction

At the heart of most security events - the kind in which malicious people get control of computers that do not belong to them - is usually one of two errors: configuration problems and bad computer code. And bad code is emerging as the more important one. As the hacker Mudge told President Clinton, back in February 2000 in a White House meeting of internet and software experts, "People write software sloppily. Nobody checks it for mistakes before it gets sold." In nearly nine years, little has changed - except the criminals and nation-states are even more likely to attack buggy software than they were earlier.

This document, along with two other initiatives, are the first steps toward allowing buyers and users of software to start fightin/ back. This document helps enable buyers of custom software to make code writers responsible for checking the code and for fixing security flaws before software is delivered. A second project, called the CWE/SANS Top 25 software errors prioritizes the programming errors that cause the most security problems. A third project, the GSSP assessments, allow employers to ensure that programmers know how to write secure code.

This is a living document. If you can find a way to make it better or more useful or more current, please email us at procurement@sans.org.

Primary Authors/Contributors

Will Pelgrin, CSO New York State
Jim Routh, CISO, Depository Trust and Clearing Corporation
Jeff Williams, Aspect Security

Please note that the proposed procurement guidelines incorporate substantial language from the OWASP Secure Software Contract Annex.

QUESTIONS/COMMENTS

If you have questions for comments or are willing to share best practices or actual contracts please send an email to procurement@sans.org.

TRANSLATION

Japanese

DISCLAIMER

THIS DOCUMENT SHOULD BE CONSIDERED GUIDANCE ONLY. IT IS STRONGLY RECOMMENDED THAT YOU CONSULT A QUALIFIED ATTORNEY TO HELP YOU NEGOTIATE A SOFTWARE CONTRACT.

Please be advised that there is no warranty, expressed or implied, and no assumption of any legal liability or responsibility for any third party's use, or the results of such use of this Document.

January 2009

Application Security Procurement Language

I. GENERAL

The Vendor shall agree to maximize the security of the software development throughout the term of this Contract according to general industry standards including but not be limited to the following terms and conditions.

The Contract shall clarify the security-related rights and obligations of all the parties to a software development relationship including any third-party contractors, subcontractors or other entities hired by Vendor.

The Vendor shall agree in writing that the terms of this Contract shall apply to Vendor's employees, as well as to third party contractors and subcontractors that will be employed by Vendor for the Contract.

The Vendor shall take all actions necessary to protect information regarding security issues and associated documentation, to help limit the likelihood that vulnerabilities in operational Purchaser's software are exposed.

Consistent with the provisions of this Contract, the Vendor shall use the highest applicable industry standards for sound secure software development practices to resolve critical security issues as quickly as possible. The "highest applicable industry standards" shall be defined as the degree of care, skill, efficiency, and diligence that a prudent person possessing technical expertise in the subject area and acting in a like capacity would exercise in similar circumstances.

Personnel

The Vendor shall identify in writing the person who will be responsible for overall security of the application development, management, and update process throughout the Contract period. The person identified shall be a single senior technical security specialist, to be known as the project Security Lead. The Security Lead shall certify in writing the security of each deliverable.

Security Training

The Vendor shall be responsible for verifying that all members of the developer team have been successfully trained in secure programming techniques.

Pre-contract award, the Vendor shall document the process including training courses that their application developers have taken prior to developing applications.

Pre-contract award, the Vendor shall certify to the Purchaser that only application developers who have received appropriate level of formal training on secure application development and passed a competency test on application security shall be involved in the Contract.

Background Checks of Developers

Vendor shall perform appropriate background investigation of all development team members and shall certify that all individuals who will be involved in this Contract and the software development process have cleared the background investigation.

Vulnerabilities, Risks and Threats

The Vendor shall agree in writing that he will strive to identify vulnerabilities, risks and threats as early as possible at any time during the software lifecycle. The software lifecycle shall mean from development, management, and updates through retirement of such application.

The Vendor shall identify the key risks to the important assets and functions provided by the application. The Vendor shall conduct an analysis of the Top 25 software errors, or most common programming errors, and document in writing that they have been mitigated. The Vendor shall conduct risk assessment(s) to determine and prioritize risks, enumerate vulnerabilities and understand the impact that particular attacks might have on an application to ensure it meets applicable contractual obligations, regulatory mandates and security best practices and standards.

The Vendor shall share with purchaser in writing all security-relevant information regarding the vulnerabilities, risks and threats to the application immediately and completely upon identification. Such security documenta-tion shall describe security design, risk analysis, or issues.

Application Development

Pre-contract award, the Vendor shall provide purchaser written documentation detailing their application development, patch management and update process. The documentation shall clearly identify the measures that will be taken at each level of the process to develop, maintain and manage the software securely.

The Vendor shall provide secure configuration guidelines in writing to the Purchaser that fully describe all security relevant configuration options and their implications for the overall security of the software. The guideline shall include a full description of dependencies on the supporting platform, including operating system, web server, and application server, and how they should be configured for security. The default configuration of the software shall be secure.

Pre-contract award, the Vendor shall specify in writing to the Purchaser what industry security standards and level of care that they follow.

Pre-contract award, the Purchaser shall specify in writing to the Vendor what additional security standards and level of care will be applicable in the application software lifecycle.

The Vendor shall agree in writing to comply with such standards and level of care. The Vendor shall provide written documentation to the Purchaser that clearly explains the design for achieving each of the security requirements. The Vendor shall provide and follow a set of secure coding guidelines. These guidelines will indicate how code should be formatted, structured, and commented. All security-relevant code shall be thoroughly commented. Specific guidance on avoiding common security vulnerabilities shall be included. Also, all code shall be reviewed by at least one other Developer against the security requirements and coding guideline before it is considered ready for test.

II. DEVELOPMENT ENVIRONMENT

(a) Secure Coding: The Vendor shall disclose what tools are used in the software development environment to encourage secure coding.
(b) Configuration Management: The Vendor shall use a source code control system that authenticates and logs the team member associated with all changes to the software baseline and all related configuration and build files.
(c) Distribution: The Vendor shall use a build process that reliably builds a complete distribution from source. This process shall include a method for verifying the integrity of the software delivered to Client.
(d) Disclosure: The Vendor shall document in writing to the Purchaser all third party software used in the software, including all libraries, frameworks, components, and other products, whether commercial, free, open-source, or closed-source.
(e) Evaluation: The Vendor shall make reasonable efforts to ensure that third party software meets all the terms of this agreement and is as secure as custom developed code developed under this agreement.

III. TESTING

(a) General: The Vendor shall provide and follow a security test plan that defines an approach for testing or otherwise establishing that each of the security requirements has been met. The level of rigor of this test process shall be detailed in the plan. The vendor shall implement the security test plan and provide the test results to Client in writing.
(b) Source Code: The Vendor shall agree in writing to the Purchaser that during the application development lifecycle process the source code shall be evaluated to ensure the requirements of this Contract including the security standards, policies and best practices are followed. The Vendor shall have a well-documented procedure and framework for conducting code reviews.
(c) Vulnerability and a Penetration Test: The Vendor shall agree in writing that prior to production the application shall undergo vulnerability and a penetration test.

Post production, the Vendor shall perform contractually agreed upon security scans (with the most current signature files) to verify that the system has not been compromised during the testing phase.

The Vendor shall provide to Purchaser written documentation of the results of the scans and tests along with a mitigation plan.

The Vendor shall agree in writing that these vulnerabilities shall be mitigated within a pre-negotiated period.

Patches and Updates

The Vendor shall provide notification of patches and updates affecting security within a pre-negotiated period as identified in the patch management process throughout the software lifecycle.

The Vendor shall apply, test, and validate the appropriate patches and updates and/or workarounds on a test version of the application before distribution.

The Vendor shall verify and provide written documentation that all updates have been tested and, prior to production, installed.

The Vendor shall verify application functionality, based upon pre-negotiated procedures, at the conclusion of patch updates, and provide documentation of the results.

Tracking Security Issues

The Vendor shall track all security issues uncovered during the entire software lifecycle, whether a requirements, design, implementation, testing, deployment, or operational issue. The risk associated with each security issue shall be evaluated, documented, and reported to Purchaser as soon as possible after discovery.

IV. DELIVERY OF THE SECURE APPLICATION

The Vendor shall provide a "certification package" consisting of the security documentation created throughout the development process. The package shall establish that the security requirements, design, implementation, and test results were properly completed and all security issues were resolved appropriately.

The Vendor shall resolve all security issues that are identified before delivery. Security issues discovered after delivery shall be handled in the same manner as other bugs and issues as specified in this Agreement.

Self-Certification

The Security Lead shall certify to the purchaser in writing that the software meets the security requirements, all security activities have been performed, and all identified security issues have been documented and resolved. Any exceptions to the certification status shall be fully documented with the delivery.

No Malicious Code

Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application, including computer viruses, worms, time bombs, back doors, Trojan horses, Easter eggs, and all other forms of malicious code.

V. SECURITY ACCEPTANCE AND MAINTENANCE

Acceptance

The software shall not be considered accepted until the Vendor certification package is complete and all security issues have been resolved.

Investigating Security Issues

After acceptance, if security issues are discovered or reasonably suspected, Vendor shall assist Purchaser in performing an investigation to determine the nature of the issue.

Latest Whitepapers

Analyzing Network Traffic With Basic Linux Tools
By Travis Green

People, Process, and Technologies Impact on Information Data Loss
By Paul Janes

An Analysis of the Snort Data Acquisition Modules
By Christopher Murphy

Latest Tweets

No Tweets available at this time. Please check back soon!

Contact Us

(301) 654-SANS (7267)
Mon-Fri 9am - 8pm EST/EDT
info@sans.org

"As a security professional, this info is foundational to do a competent job, let alone be successful."
- Michael Foster, Providence Health & Security

"SANS is a great place to enhance your technical and hands-on skills and tools. I thoroughly recommend it."
- Aaron Waugh, Datacom NZ Ltd

"Just amazing content and instruction, it's really a 'must do' for any info sec professional."
- Mark Austin, PHH Mortgage