Welcome to Innominds Blog
Enjoy our insights and engage with us!

Enhancing Product Security By Adopting Shift Left Security Approach: Secure SDLC

By Venkatesh Gottipati,

Secure Software Development Life Cycle

“Necessity may be the mother of invention, but adopting security is an investment, not an expense.”

In the epidemic of digital encyclopaedia, threat landscape has changed drastically and is essential to encourage our business leaders to adopt a culture of security to impart global security best practices from day one of the development process. Organisations are well concentrated to provide innovative products to their customers ahead of the competition. But with the increasing security concerns and business risks, it is equally important to integrate security into every step of Software Development Life Cycle (SDLC) and the process is defined as secure SDLC. One of the basic principles of secure SDCL is shifting security left.

Secure SDLC integrates global security practices and security tools into the SDLC model and ensures security assurance activities like architecture analysis, penetration testing and code review are an integral part of the development and thus helps to discover security bugs at the earliest.

Why Secure SDLC

Many companies consider security in their applications as part of the quality assurance process after their software has been fully developed towards the end of the software development lifecycle. But the cost and time of remediating the security vulnerabilities in post-production is higher compared to addressing it in the earlier stages of the SDLC. A good deal of advantages can be achieved by adopting security from initial phase of development life cycle.

  1. Early detection of security vulnerabilities brings time and cost efficiency
  2. Increases the security posture and gains customers trust
  3. In-depth coverage of security in terms of configuration and architectural designs
  4. Security risks are identified and managed at every stage to achieve acceptable level of risk
  5. Spreading security awareness by collaborating with multiple teams involved

Approach and Methodology

The formal way of implementing security as SAST and DAST to identify the vulnerabilities in the developed product uncovers the security posture of architectural design and intermediate components configurations. Integrating security into SDCL enhances the security on front end process. To achieve this efficiently, the security requirements for every phase should be strictly outlined and enforced to review the controls implemented prior to moving to the subsequent phases.

Vector 3

 Tools and Integration


1. Planning and Analysis

Any product development initiates by gathering the requirements and system analysis. In this phase, security experts advise to incorporate applicable security policies, global security standards and regulatory compliance as an important factor to avoid later conflicts.

Risk analysis is carried out based on the type of information application is processing, functionality and use-case modelling.

Once the framework and languages are decided, developers and security experts should collaboratively think the kind of security risks associated with the technologies being used and which risks require attention during design and development phase to achieve a secure product with minimal effort.

This phase engages to derive security requirements from business functionality and build an access control matrix for resources and capabilities.

Planning and Analysis

2. Architecture and Design

This phase address the risk considered in the previous phase using threat modelling and architecture review.

Current threats and new risks associated with the internal components are evaluated, prioritized and mitigated at the design phase to counter the security bugs in development and deployment stages.

Threat Modelling

The two main objectives of threat modelling are:

  1. Implementing proper security controls adherence to requirements & policies
  2. Investigating assets involved and potential threats to implement appropriate counter measures against threats. With these contexts, threat modelling is confined to address in four aspects.
    1. Software Centric
    2. Asset Centric
    3. Attacker Centric
    4. Threat Centric

Software Centric

This phase engages to analyse the design of the system by evaluating the software architecture diagrams like component diagrams, data flow diagrams, use case diagrams, etc.

This approach examines the de-facto standards of network and other systems involved in the process.

Example: Threat Analysis & Modelling (TAM), and Microsoft Secure Development Lifecycle framework (SDL) tools validate the systems being analysed through data flow diagrams.

Asset Centric

This phase involves in identifying the important assets of an organization such as systems (firewalls, deployment servers etc) and data assets. Data assets are interpreted to prioritize the risk levels based on the sensitivity and peculiarity to the potential attackers.

Attacker Centric

This phase engages to profile the skill set, characteristics and the desire of potential attackers to exploit various assets of an organization.

These profiles are further analysed to understand the attack pattern and exploitation techniques perpetrated by an attacker and thus helps to implement the counter measures against potential attacks.

Threat Centric

Threat Centric is a comprehensive approach to implement end-to-end security in highly interconnected cyber ecosystem. It uses the metrics from above approaches and maps the attack surface considering the known and unknown threat agents leading to impact any of the assets in the organization.

The primary objective is to design an end-to-end comprehensive security policy by quantifying the organization’s cyber ecosystem risks considering internal and external threat factors.

STRIDE and PASTA are few threat modelling methodologies that are efficiently used for this approach.

Vector 4

3. Development/Implementation

In the initial phase of development, product is developed at unit level using the technology stack decided at the earlier stage and then developed units are integrated to build the entire product.

Here, security experts ensure to develop the secure code by following global security coding standards and adopt all security controls identified in the design phase for every unit developed.

Initially, every unit of code is reviewed for security standards and then overall integrated build is verified either manually or by using automated SAST tools.

The primary objective is to implement security controls for all potential threats and existing vulnerabilities. Below are the list of industry best security controls advised to implement during development phase.

S. No Secure Code Review Best Practices
Input Validation
1 Conduct data validation on all trusted and untrusted sources for malicious characters
2 Specify proper charater sets, such as UTF-8, for all sources of input
3 Encode data to a common character set before validation
4 All validation failures should result in input rejection
5 Validate all client provided data before processing including URL's, parameters & HTTP headers
6 Verify header values of both requests and responses contain only ASCII characters
7 Validate data for expected data types, length and range
8 There should be a centralized input validation routine for the application and it should check
descretly null bytes (%00), new line characters(%0d, %0a, \r, \n), dot dot slash(../)
Output Encoding
9 Conduct all encoding on a trusted system (e.g., the server)
10 Encode all characters unless they are known to be safe for the intended interpreter
11 Sanitize all output of un-trusted data to operating system commands and data to queries for SQL, XML, and LDAP
12 Contextually output encode all data returned to the client that originated outside the
application's trust boundary. HTML entity encoding is one example, but that does not work in all cases
Authentication and User Management
13 Require authentication for all the pages and resources, except those specifically intended to be public 
14 All authentication controls and password hashing must be enforced to a trusted system (a server)
15 All authentication controls should fail securely
16 Use only HTTP POST requests to transmit authentication controls
17 Enforce password policies confined to the regulatory standards
18 Security policies are configurable (not hardcoded)
19 Standard security frameworks are used (instead of custom code)
20 SSL is used to protect user credentials and authentication tokens
21 Application handles suspicious events such as multiple failed logon attempts, session replay and attempted access
to restricted resources
Session Management
22 No session parameters passed in URLs
23 Session cookies expire in a reasonably short time
24 Session cookies are encrypted
25 Session data is being validated
26 Private data in cookies is kept to a minimum
27 Application avoids excessive cookie use
28 Session id is complex
29 Session storage is secure
30 Application properly handles invalid session ids
31 Session limits such as inactivity timeout are enforced
32 Logout invalids the session
33 Disable client side caching on pages containing sensitive information
34 Use only trusted system objects, eg: server side session objects for making access authorization decisions
35 Access controls should fail securely
36 Seggregate privileged logic from other application code
37 Restrict access to protected URL's and functions only to authorized users
38 Restrict direct object reference to only authorized users
39 Authorization cannot be bypassed by cookie manipulation
40 ACLs are configured for all files and define roles properly
41 Use "referer" header as supplemental check only, it should never be sole authorization check, as it can be spoofed
42 Sensitive data has been secured in memory, storage and transit
43 All cryptographic functions used to protect secrets must be implemented on trusted system (Server)
44 Cryptographic modules should fail securely
45 Cryptographic modules used by the application should be compliant to FIPS 140-2  or equivalent standard
46 Establish and utilize a policy and process for how cryptographic keys will be managed
47 SSL provider supports only strong algorithms
Exception Handling
48 Do not disclose sensitive information in error responses, including system details, session identifiers or account information
49 Use error handler that do not display debugging or stack trace information
50 Implement generic error messages and use custom error pages
51 Error handling logic associated with security controls should deny access by default
52 All logging controls should be implemented on trusted server 
53 Restrict access to logs to only authorized individuals
54 Do not store sensitive information on logs, including unnecessary system details, session identifiers or passwords
55 Log all input validation failures, authentication attempts, access control failures, system exceptions and other failure events
Database Security
56 Use strongly typed parameterized queries
57 Utilize input validation and output encoding and ensure to address meta characters
58 The application should use the lowest level of privilege when accessing the database
59 Connection string should not be hardcoded within the application, and should be stored in a separated configuration file on trusted server with encryption
60 Use stored procedures to abstract data access and allow for removal of permissions to the base tables in database
61 Remove or change all default database administrative passwords
General Coding Practices
62 Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, libraraies and configuration files
63 Use tested and approved managed code rather than creating new unmanaged code for common tasks
64 Review all secondary applicatons, third party code and libraries to determine business necessity and validate safe functionality
65 Ensure system calls have their return status checked
66 No exposures to buffer overruns
67 System calls have their return status checked
68 Safe update - ensure libraries are up to date
69 Efficient memory usage


Tools Used: Checkmarx, Codestriker, CodeBrag & Rhodecode are few automated tools used to perform secure code review.

4. Testing/Staging

Once the complete software is built, it is deployed in the testing environment to carry out functional, non-functional and performance tests. At this point, security experts perform full-blown security assessment, which includes both vulnerability assessment and penetration testing. The main objective of penetration testing is to identify business logic vulnerabilities present in the system. Grey box penetration testing is carried out to identify exploitable vulnerabilities present in the system and mitigating these vulnerabilities ensures the complete coverage of security to the end product to deploy in the production environment.

Tools Used: Burp Suite, OWASP ZAP, Nessus, Ironwasp, etc. are few open-source and enterprise edition tools used to perform security assessment of entire product.

5. Production Deployment

Many organizations strongly believe that building the product with complete security controls at every level is adequate to protect from external threats, but to protect from ever evolving techniques used by the evil hackers to threaten the organizations, it is important to keep an eye on incoming and outgoing traffic.

SIEM tools are integrated into the infrastructure for continuous monitoring of traffic and security analysts perform log analysis and investigate triggered security incidents.

Tools Used: Splunk, McAfee, IBM Qradar, etc.


The world matures digitally with new inventions and incorporating security gains customer trust and enhances the usage of software product. To address the threat landscape efficiently organizations should implement the security as a built-in feature rather than add-on to the product.

Author Bio: With more than 15 years of experience in Information Security across APAC and North America, Venkat leads our Enterprise Security business unit and is responsible for custom solutions and service delivery. He works closely with our Enterprise and ISV clients including start-ups and helps achieve their Enterprise Security objectives. You can reach out to him at vgottipati@innominds.com for any advisory and consultative thought leadership on the topic of Enterprise Security.

Topics: Enterprise Security

Venkatesh Gottipati

Venkatesh Gottipati

Practice Lead - Enterprise Security

Subscribe to Email Updates


Show More

Recent Posts