# Vulnerabilities Start While Code Is Written: Secure Coding and Secure SDLC

**URL:** https://securesys.com.tr/en/learning/source-code-analysis/secure-coding-and-secure-sdlc-guide

![Vulnerabilities Start While Code Is Written: Secure Coding and Secure SDLC](/images/bilgi-merkezi/covers/cover-kod-02.webp)

A software vulnerability usually does not appear at the moment an attacker reaches the system.

In fact the flaw was created much earlier.

A small mistake made while a developer writes a new function, creates an API endpoint, processes user input or prepares a database query can turn into a critical security incident months later.

For this reason, modern cybersecurity no longer asks only:

**"Is the application secure against attacks?"**

A more important question is being asked:

**"Was this application developed securely?"**

The difference between the two is considerable.

Testing an application after it has been built is a reactive security approach.

Building an application securely from the very beginning is a proactive one.

That is the fundamental reason concepts such as **Secure Coding, Shift Left Security, DevSecOps and Secure SDLC** keep gaining importance today.

Because it is possible to find a vulnerability in the production environment.

But finding that same vulnerability at the moment the code is written is far more valuable.

It is faster.

It is cheaper.

It is easier to fix.

And most importantly, the attacker has not yet had the chance to use it.

### \1. How Does a Vulnerability Get into the Code?

A software developer's basic task is to turn a defined business need into a working function.

For example, in an e-commerce application a developer may be asked for this feature:

**"Let the user enter an order number and view the order details."**

The developer creates the necessary API endpoint.

Writes the database query.

Takes the order number as a parameter.

Returns the result to the user.

The function works.

When the test team enters an order number, the correct order is displayed.

Functionally the system is a success.

But the critical question is this:

#### Can the user view only their own orders?

If the developer has checked the order number but has not verified that the order really belongs to the signed-in user, a security problem arises.

An attacker can change the order number in the URL or in the API request.

For example:

/api/order/10541

instead of:

/api/order/10542

If sending that displays another user's order details, there is an authorisation problem in the system.

Technically the application works.

But it is not secure.

This example explains the fundamental problem of software security very well:

**Functional correctness and security are not the same thing.**

Code can work correctly and still contain a vulnerability.

### \2. Why Should Software Security Start During Development?

In traditional software development processes, security is mostly addressed in the final stages.

The process usually proceeds like this:

**Analysis → Design → Development → Test → Security Testing → Production**

Here, security testing sits almost at the end of the process.

This approach was widely used in the past.

But with modern software development methods, serious problems have begun to emerge.

Today organisations may release application updates:

- weekly,
- daily,
- and in some cases dozens of times a day.

Microservice architectures, API-based systems, container technologies and CI/CD pipelines have significantly increased the speed of software development.

Manual checking by the security team at the end of every release is therefore no longer a scalable approach.

Security controls must be moved inside the software development process.

The security team should not be merely a control mechanism that appears at the end of a project.

Security

**must be integrated into design, development, testing and deployment alike, starting from the design stage.**

That idea sits at the heart of the Secure SDLC approach.

### \3. What Is Secure Coding?

Secure Coding means software developers writing code while taking security risks into account.

The aim here is not merely to produce code that is syntactically correct or functionally working.

How the code could be used by an attacker must also be considered.

In a Secure Coding approach the developer should ask:

- Can I trust this user input?
- What happens if this parameter is manipulated?
- Is the user really authorised to access this function?
- Is sensitive data ending up in the logs?
- Does the error message reveal too much?
- Is this query open to an injection attack?
- Is user input written directly into HTML output?
- Can the file upload mechanism be abused?
- Are API keys present inside the code?
- Does the library being used have a vulnerability?

When these questions become a natural part of the development process, an organisation's security level rises considerably.

Secure Coding does not consist only of certain programming techniques.

It is also a **development culture.**

### \4. The "Never Trust User Input" Principle

One of the most fundamental principles of Secure Coding is this:

**Never Trust User Input.**

That is:

**Do not trust any data coming from the user directly.**

An attacker does not have to use the fields on a web form.

They can modify HTTP requests directly.

They can send manual requests to API endpoints.

They can manipulate header information.

They can change cookie values.

They can edit parameters inside a JSON body.

So even fields not visible in the user interface can be changed by an attacker.

For example, if the system sends the user role like this:

role=user

the attacker may try changing it to:

role=admin

The fact that a field cannot be changed by the user on the front end is not a security control.

The real control must be applied on the back end.

One of the critical rules of secure software development is therefore:

**Security controls must always be applied on the trusted server side.**

### \5. Why Does Input Validation Matter?

Input validation is checking whether data sent by a user or external system is in the expected format.

For example, an age field may be expected to receive only an integer between 0 and 120.

A phone number may have a particular format.

An email address may have a particular character structure.

A product quantity cannot be negative.

A transaction date must fall within certain limits.

These checks matter not only for the application to work correctly but also for security.

But there is an important distinction here:

Input validation alone does not prevent every attack.

The fundamental solution to SQL Injection, for instance, is not input validation alone.

**Parameterized queries or prepared statements** must be used for database operations.

Likewise, filtering special characters alone is not enough for XSS.

Output must be encoded appropriately for the context it appears in.

The basic principle of Secure Coding is this:

**The right control must be applied for each security problem.**

### \6. How Does SQL Injection Arise While Code Is Written?

SQL Injection is one of the most classic examples in software security.

Consider a developer adding data taken from the user directly into an SQL query.

The simplified logic may look like this:

SELECT * FROM users WHERE username = 'user_input'

If user input is added to the query through direct string concatenation, an attacker can change the structure of the query.

In that case the problem did not begin at the database server.

Nor did it begin at the firewall.

The problem began on this line:

**User input was added to an SQL query in an insecure way.**

The secure approach is to use a parameterized query.

The database then treats user input as data rather than as part of the SQL command.

This small design difference can have very large security consequences.

This is where the power of Secure Coding shows itself.

The vulnerability was prevented before the attacker appeared.

### \7. How Does Cross-Site Scripting Arise at Code Level?

Cross-Site Scripting, or XSS, can occur when user-controlled data is passed to a web page without being processed safely.

Consider an application that displays user comments.

The user writes a comment.

The application saves it to the database.

The comment is later added directly into HTML.

If the output is not encoded correctly, an attacker can send JavaScript content that the browser will execute.

Here again, the problem began in the application's basic coding approach.

The developer made this assumption:

**"Data coming from the database is safe."**

But the data in the database may have been entered by a user earlier.

In a secure development approach, therefore, it is not only the source of the data that matters but the **context in which it is used**.

Data used inside HTML may be handled one way,

data used inside JavaScript another,

and data used inside a URL another again.

These details show why Secure Coding standards are necessary.

### \8. Why Is Broken Access Control One of the Most Dangerous Coding Errors?

Authorisation problems are among the most critical security risks in modern applications.

Because in most cases the attacker does not need to develop a complex exploit.

It is enough to notice the flaw in the application's access control mechanism.

For example, an API endpoint may look like this:

GET /api/customer/285

This endpoint returns customer information.

If the back end checks only whether the user is logged in, but not whether the user is authorised to view customer 285, an attacker can change the ID values.

Flaws of this kind can sometimes be missed by automated scanning tools too.

Because the system technically does perform a login check.

The problem is in the business logic.

In a Secure Coding approach, therefore, not only authentication but also **authorisation** must be treated as a separate security control.

For every critical operation this question should be asked:

#### Is this user really authorised to perform this operation?

### \9. Authentication and Authorization Are Not the Same Thing

One of the mistakes made most often in software development is confusing authentication with authorisation.

Authentication answers this question:

**"Who are you?"**

Authorization answers this one:

**"Are you allowed to do this?"**

A user may have signed in with the correct username and password.

That does not mean they can access all data.

An employee may be able to sign in to the company system, for example.

But they may not be authorised to view human resources data.

Likewise, a customer can see their own account activity but must not be able to reach another customer's.

Authorisation checks must therefore be a natural part of every critical function.

### \10. Insecure File Upload Functions

File upload mechanisms are among the attack surfaces encountered most often in applications.

A profile photo upload feature looks simple.

But if the developer checks only the file extension, an attacker can deceive the system.

In a secure file upload mechanism, many controls must be assessed together.

For example, controls such as:

- file extension,
- MIME type,
- actual file content,
- maximum file size,
- file name,
- the directory it is saved to,
- execution permissions,
- access method

all matter.

One of the most critical principles is keeping uploaded files as far as possible from areas the application can execute.

This example shows that Secure Coding covers not just a single line of code but architectural decisions too.

### \11. The Hard-Coded Password and API Key Problem

It is quite common for developers to add temporary information into code for testing.

For example:

- a test database password,
- an API key,
- a cloud access key,
- an SMTP password,
- a private token

may be written into the source code.

The problem begins here:

The code is pushed to a Git repository.

The developer later deletes that information from the file.

But the information may remain in the repository history.

So even though the sensitive data appears technically deleted, an attacker can reach it through the Git history.

For this reason **Secret Scanning** has become an important control in modern Secure SDLC processes.

Sensitive information should not be kept inside code.

Environment variables, a secrets manager or vault systems should be used instead.

### \12. Error Messages Can Create Vulnerabilities

Detailed error messages are very useful for developers in a development environment.

Seeing which file the application errored in or which database query failed makes the problem easier to solve, for instance.

But the same information is highly valuable to an attacker in a production environment.

Detailed error messages can reveal:

- file paths,
- framework information,
- database structures,
- the technologies in use,
- internal host names,
- stack trace information.

Secure Coding is therefore not merely about preventing functions that are open to attack.

**Error handling and information disclosure are part of secure coding too.**

### \13. What Should Secure Logging Look Like?

Logging is critically important for incident response and security monitoring.

But incorrect logging methods can create new security risks.

Serious problems can arise if an application logs information such as:

- user passwords,
- credit card details,
- access tokens,
- session IDs,
- personal health data,
- private API keys.

Developers must therefore have clear standards about which information may be logged.

Events that matter for security must be logged.

For example:

- failed login attempts,
- authorisation violations,
- critical configuration changes,
- admin operations,
- suspicious API calls

can be recorded.

But logs must not contain sensitive information an attacker could use.

### \14. Insecure Use of Cryptography

Cryptography is one of the areas of software security applied incorrectly most often.

Developers sometimes try to build their own encryption algorithms.

This is usually a bad idea.

The basic principle in cryptography is this:

**Do not develop your own cryptographic algorithm.**

Standard, trusted and current algorithms should be preferred.

Choosing a strong algorithm is not sufficient on its own either.

Key management must also be secure.

A strong encryption algorithm may be in use, for example, but if the encryption key is kept in plain text inside the source code the system is still insecure.

Passwords should not be stored by encrypting them directly either.

Appropriate password hashing algorithms and correct parameters must be used for password storage.

Secure Coding is therefore not about choosing an algorithm's name but about designing the whole cryptographic life cycle correctly.

### \15. Secure Default Settings

The Secure by Default principle states that an application's default behaviour should be secure.

For example, when a new user is created the default role should not be:

Administrator

The lowest privilege level should be assigned.

When a new API endpoint is created it should not be open to everyone.

The necessary authentication and authorisation controls should be applied from the outset.

When a new file is created it should not be given public access.

This approach is closely related to **Least Privilege**.

Users and services should hold only the privileges they need to perform their tasks.

### \16. Dependency Security and Open Source Libraries

A significant part of the applications developed today consists of third-party libraries.

When a developer adds a single package, dozens of other dependencies may come with it.

This creates a significant risk for the software supply chain.

Your code may be entirely secure.

But the open source library you use may contain a known critical vulnerability.

Secure Coding must therefore not cover only the code the developer writes.

The security of the components used must be checked as well.

**Software Composition Analysis – SCA** solutions can be used in this area.

SCA tools analyse:

- the packages used,
- their versions,
- known vulnerabilities,
- dependency relationships.

In a modern code security approach, therefore, the trio of:

**SAST + SCA + Secret Scanning**

forms an important foundation.

### \17. The Cost of Finding a Vulnerability Early

When a security problem is found during development it can usually be solved with a few lines of code.

Once the same problem reaches the production environment the process becomes far more complex.

When a critical vulnerability is detected in a live system, for example, these steps may be needed:

- incident assessment,
- assigning the development team,
- code change,
- creating a new build,
- repeating the test processes,
- an emergency release,
- system update,
- log analysis,
- checking for attacker access,
- an incident response process if required.

If a data breach has occurred, matters become far more serious.

The cost of a vulnerability is therefore not only the time taken to fix it.

Business disruption, human resources, reputational damage and possible regulatory consequences can also arise.

In a modern security approach, therefore:

**"preventing the flaw from occurring" is more valuable than "finding the flaw"**

### \18. What Is Shift Left Security?

Shift Left Security is the approach of moving security controls into earlier stages of the software development life cycle.

Software development processes are usually visualised from left to right:

**Planning → Design → Coding → Build → Test → Deployment → Production**

In the traditional model, security sits on the right — at the test or production stage.

The Shift Left approach moves security to the left.

Security controls therefore start being applied from the design and development stages onwards.

For example:

Security requirements can be defined at the planning stage.

Threat modelling can be done at the design stage.

Secure Coding standards can be used during coding.

Secret Scanning can run at commit time.

SAST and SCA can be applied during the build.

DAST can be performed at the testing stage.

A manual pentest can be carried out before release.

This approach takes security out of a single control point and turns it into a continuous process.

### \19. Does Shift Left Eliminate the Security Team?

No.

The Shift Left Security approach is sometimes misunderstood.

The aim is not to hand security responsibility entirely to developers.

The aim is to bring the security team's knowledge and controls into the development process earlier.

Developers are not expected to become security specialists.

But they do need basic knowledge of secure coding.

The security team's role continues as:

- defining security standards,
- integrating security tools into development processes,
- validating critical findings,
- guiding developers,
- assessing risks,
- testing complex attack scenarios.

In the most successful structures, development and security teams work together rather than against each other.

### \20. The Security Champion Model

In large development teams it may not be realistic for every developer to have deep security knowledge.

Many organisations therefore use the **Security Champion** model.

A Security Champion is a developer or technical team member within the software team who has more knowledge of security.

This person acts as a bridge between the security team and the development team.

Their responsibilities can include:

- conveying Secure Coding principles to the team,
- assessing security findings,
- supporting developers,
- tracking the application of security controls,
- coordinating with the security team.

This model is particularly effective in large DevSecOps organisations.

### \21. What Is Secure SDLC?

Secure SDLC — Secure Software Development Life Cycle — is the integration of security into the whole software development life cycle.

In this approach security is not a separate project.

It is a natural component of the software development process.

An example Secure SDLC model might look like this:

#### \1. Planning

Security requirements are defined.

The types of data the application will process are assessed.

Critical functions are identified.

#### \2. Design

Threat modelling is carried out.

The authentication and authorisation architecture is defined.

Trust boundaries are established.

#### \3. Development

Secure Coding standards are applied.

Code review processes are run.

#### \4. Commit

Secret Scanning is applied.

Code repository security checks are run.

#### \5. Build

SAST and SCA analyses can be performed.

Critical security findings can stop the pipeline.

#### \6. Test

DAST and API security tests can be carried out.

#### \7. Release

A manual pentest can be applied for critical systems.

#### \8. Production

The application is monitored with logging, SIEM, WAF and security monitoring systems.

This structure genuinely integrates security into the software life cycle.

### \22. DevSecOps and Code Security

DevSecOps means integrating security into DevOps processes.

While DevOps accelerates the process between development and operations teams, DevSecOps brings security into that structure.

The important point here is automation.

When a developer pushes new code, for example, the CI/CD pipeline can automatically perform these steps:

**Secret Scanning → SAST → SCA → Build → Security Quality Gate → Deployment**

When a critical security problem is detected, the build can be stopped.

This mechanism means the developer learns about the security problem within minutes rather than months later.

DevSecOps is therefore one of the important components of modern Secure SDLC structures.

### \23. What Is a Security Quality Gate?

A Quality Gate expresses the criteria software must meet before it can move to the next stage.

From a security perspective those criteria might be:

- There must be no critical SAST finding.
- There must be no critical dependency vulnerability.
- No hard-coded secret must be detected.
- Vulnerabilities above a certain CVSS level must be fixed.

This approach takes security out of the realm of advice and makes it a technical rule of the software development process.

But designing the Quality Gate mechanism correctly matters.

Rules that are too strict or badly configured can stop developers' processes unnecessarily.

Rules that are too loose can let real security risks through.

A risk-based approach should therefore be preferred.

### \24. Why Does Secure Coding Training Matter?

The same security errors appearing again and again during source code analysis is an important signal.

If an organisation's different applications continually show problems such as:

- SQL Injection,
- Broken Access Control,
- XSS,
- hard-coded credentials,
- insecure file upload,

the issue may not belong to a single application.

There may be a systematic gap in the development processes.

Secure Coding training then becomes an important part of the security programme.

But it is not enough for training to be purely theoretical.

Real code examples suited to the programming languages and frameworks developers use must be included.

Giving Java examples to a Java developer,

C# examples to a .NET developer,

and JavaScript security examples to a front-end developer

significantly increases the impact of the training.

### \25. Where Does Source Code Analysis Sit Within Secure SDLC?

Source code analysis is one of the critical control points of Secure SDLC.

But on its own it does not deliver complete security.

The ideal approach consists of complementary security layers.

For example:

**Threat Modeling** → surfaces design risks.

**Secure Coding** → tries to prevent the vulnerability from occurring.

**SAST** → detects potential security problems within the code.

**SCA** → analyses the risks of third-party components.

**Secret Scanning** → detects sensitive information inside the code.

**DAST** → analyses the running application.

**Pentest** → assesses security from a real attacker's perspective.

When these controls work together, a stronger Application Security programme emerges.

### \26. Secure Software Is a Process, Not a Product

An organisation buying a SAST product does not mean it has established a Secure SDLC.

Likewise, having a pentest once a year does not create a secure software development culture.

Secure software development consists of:

**people + process + technology**

On the people side there are developers and security teams.

On the process side there are Secure Coding standards, code review, security gates and security policies.

On the technology side there are SAST, SCA, DAST, Secret Scanning and other Application Security tools.

When these three components do not work in balance, the security programme remains incomplete.

### \27. What Should an Enterprise Secure Coding Standard Look Like?

An enterprise Secure Coding standard should contain clear security rules developers can use in their daily work.

That standard might cover topics such as:

- Input validation
- Output encoding
- Authentication
- Authorization
- Session management
- Cryptography
- Error handling
- Logging
- File upload security
- Database security
- API security
- Secret management
- Dependency management
- Secure configuration

But the standard must not remain merely a long PDF document.

It must be supported by CI/CD controls, code examples and code review processes.

The security standard then becomes part of how the developer works day to day.

### \28. Measurement in Secure Software Development

It is hard to improve a security programme you cannot measure.

Certain metrics can therefore be established within a Secure SDLC.

For example:

- number of critical vulnerabilities per application,
- recurring CWE categories,
- average time to close findings,
- proportion of repositories covered by SAST,
- proportion of developers who have had Secure Coding training,
- number of security problems found before release,
- number of vulnerabilities found after production

can be tracked.

Over time these metrics help show how the organisation's Application Security maturity is changing.

The aim is not to penalise developers on the basis of vulnerability counts.

The aim is to surface systematic problems.

### The SecureSys Approach to Secure Coding and Secure SDLC

At SecureSys we do not treat software security as a penetration test performed once the application is finished.

We believe a modern Application Security approach must consist of these layers:

**design, development, source code analysis, CI/CD security, penetration testing and continuous security monitoring**

Depending on project scope and technology stack, these controls can be assessed together:

**Secure Coding, SAST, SCA, Secret Scanning, manual source code analysis, API security testing, DAST, pentest and DevSecOps**

The aim is not to put more security controls in front of developers.

The real aim is to detect security problems as early as possible in the software development process, so that security becomes a natural part of development.

Because sustainable application security comes not from continually finding vulnerabilities but

**from preventing the same vulnerability from occurring again.**

### Frequently Asked Questions

#### What is Secure Coding?

Secure Coding means taking security risks into account while developing software and applying secure coding methods that prevent known software vulnerabilities from occurring.

#### What is Secure SDLC?

Secure SDLC is the integration of security controls into the software development life cycle from the planning stage through to production.

#### What is Shift Left Security?

Shift Left Security is the approach of moving security controls from the end of the software development process into earlier stages.

#### Are DevSecOps and Secure SDLC the same thing?

Not exactly. DevSecOps focuses on integrating security into DevOps and CI/CD processes, while Secure SDLC is a broader approach covering the whole software development life cycle.

#### Is Secure Coding training necessary?

It matters particularly in organisations that develop software. It is an effective control for reducing recurring security errors and helping developers learn secure coding principles.

#### When should SAST be run?

SAST should be run as early as possible in the development process. It can be run automatically at merge request, build or CI/CD pipeline stages.

#### Is Secure SDLC necessary when a pentest is performed?

A pentest is an important security control but does not replace Secure SDLC. A pentest detects existing vulnerabilities, while Secure SDLC aims to reduce the likelihood of those vulnerabilities occurring.

### Conclusion: Vulnerabilities Are Not Born in Production

A vulnerability may have been discovered in the production environment.

But in most cases it was not created there.

The flaw was created much earlier —

in a wrong decision at the design stage,

in a missing authorisation check,

in an insecure SQL query,

in an API key left inside source code,

in unvalidated user input

or inside an out-of-date dependency.

The fundamental goal of modern software security is therefore not only to block attacks.

**It is to prevent the vulnerability from occurring as far as possible.**

Secure Coding sits at the foundation of that approach.

Technologies such as SAST and SCA support Secure Coding with automation.

DevSecOps integrates these into the software development process.

And Secure SDLC encompasses the whole structure.

In the end, security is no longer a final check performed before release.

**Security is the entire software development life cycle.**