Secure Development Policy

SECURE
DEVELOPMENT
POLICY
1
© Distributed by Resilify.io under a Creative Commons Share Alike License.
Secure Development Policy
Version Control
Owner Version Edited By Date Change History
IS Rep 0.1 Assent 14/07/2006 First Draft
Distribution
Held Format Location Comments
By
User Digital / Physical
Status
X Status Approved By Date
Working DD/MM/YYYY
X Draft
Provisional Approval
Publication
Classification
Please refer to ISMS 02 Information Handling & Classification Procedure
X Confidential
Restricted
Unclassified
Relevance to Standard
Standard Clause Title
[ISO 27001:2013] [A14.2.1] [Secure Development Policy]
License
Licensed by Assent Risk Management via Resilify.io Under a Creative Commons Share Alike License.
2
Contents
Secure Development Policy________________________________________________________________________2

Contents_______________________________________________________________________________________________3
Secure Development Policy________________________________________________________________________4
1.0 Overview______________________________________________________________________________________4
2.0 Policy___________________________________________________________________________________________4
2.1 Software Development Approach____________________________________________________________________4
2.2 Environments__________________________________________________________________________________________5
2.3 Development Lifecycle________________________________________________________________________________5
2.4 Outsourced Development_____________________________________________________________________________6
2.5 Pen Testing____________________________________________________________________________________________6
2.6 Source Control_________________________________________________________________________________________6
2.7 Escrow_________________________________________________________________________________________________7
3.0 Related Policies_______________________________________________________________________________7
3
Secure Development Policy
1.0 Overview
This policy sets out the organization’s approach to developing systems in-house
and/or with the assistance of outsourced development.
2.0 Policy
2.1 Software Development Approach
2.1.1 Methodology
The organization uses an Agile development methodology

applied to a software development tool [TFS, Jira, Trello]
2.1.2 Stand Ups
Daily stand-up meetings include the whole development team to

discuss current and future work packages, delays, and issues.
2.1.3 Sprints
Work packages are sorted in to a two-weekly sprint by the head

of software development and the head of product development.
2.1.4 Releases
The core code base is released to the production environment

every two sprints.
4
2.2 Environments
2.2.1 Table
Name Description
Development Source code distributed by GIT.
Testing / Separate testing environment using virtual
Staging servers.
Host naming convention: test.xxxx.xxx
Production Live environment.
2.3 Development Lifecycle
2.3.1 Specification Analysis
Specifications are contained within “User Stories” and should be

registered on [TFS, Jira, Trello] as a separate item.
Information as possible should be collated from users, the

development team and the product development team, to
produce a complete specification.
2.3.2 Design
Information security considerations should be built in to the

specification of each user story.
The design should consider ways to ensure data protection and

integrity which could include:
 Input Validation
 Secure connections with other systems.
 Digital signatures.
 Logging and Clock Sync
2.3.3 Build (Dev Environment)
Code will be developed using the GIT process and completed

work committed back to the relevant branch.
5
2.3.4 Testing (Test Environment)
A Peer review process may be used to check code produced.
Each user story goes through a QA process using the original

specification and any available test script to validate the results
of the coding.
User Acceptance Testing (UAT) is used to ensure the code has

produced the expected customer experience.
2.3.5 Deployment (Production Environment)
Code will not be deployed to live before all testing is completed

satisfactorily.
Only the head of development can move code to deployment.
2.3.6 Supporting Bugs & Features
Post-release, users may raise a bug or feature request from within

the application, or via the tech services desk. In each case a user
story will be created, and the process followed from 2.3.1 above.
2.4 Outsourced Development
Where required, outsourced developers will be selected and supervised.
User stories and code branches will be assigned to outsourced developers

and code will undergo the QA process above.
2.5 Pen Testing
Every major release of the code will be Pen Tested with particular
emphasis on the OWASP Top 10.
2.6 Source Control
Source code will be held and controlled using Github.
6
2.7 Escrow
Subject to customer requirement, the source code will be held in an

Escrow service.
3.0 Related Policies
 Password Policy.
 Access Control Policy
 Patching Policy
7

Secure Development Policy

Uploaded by

Copyright:

Available Formats

Secure Development Policy

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Secure Development Policy

Uploaded by

Copyright:

Available Formats

SECURE

Standard Clause Title

[ISO 27001:2013] [A14.2.1] [Secure Development Policy]

Licensed by Assent Risk Management via Resilify.io Under a Creative Commons Share Alike License.

Secure Development Policy________________________________________________________________________2

3.0 Related Policies_______________________________________________________________________________7

2.1 Software Development Approach

The organization uses an Agile development methodology

2.1.2 Stand Ups

Daily stand-up meetings include the whole development team to

Work packages are sorted in to a two-weekly sprint by the head

The core code base is released to the production environment

2.3 Development Lifecycle

2.3.1 Specification Analysis

Specifications are contained within “User Stories” and should be

Information as possible should be collated from users, the

Information security considerations should be built in to the

The design should consider ways to ensure data protection and

2.3.3 Build (Dev Environment)

Code will be developed using the GIT process and completed

A Peer review process may be used to check code produced.

Each user story goes through a QA process using the original

User Acceptance Testing (UAT) is used to ensure the code has

2.3.5 Deployment (Production Environment)

Code will not be deployed to live before all testing is completed

Only the head of development can move code to deployment.

2.3.6 Supporting Bugs & Features

Post-release, users may raise a bug or feature request from within

2.4 Outsourced Development

Where required, outsourced developers will be selected and supervised.

User stories and code branches will be assigned to outsourced developers

2.5 Pen Testing

2.6 Source Control

Source code will be held and controlled using Github.

Subject to customer requirement, the source code will be held in an

3.0 Related Policies

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.