The importance of a secure code has never been important today than ever before. Thus, it begs the question: why don't programmers write more secure code?  From the benefits that range from security and safety of confidential information, sound market reputation, to the risks including lawsuits, poor brand image, security code isn’t just about preventing vulnerabilities. The professionals at the Software Engineering Institute of Carnegie Mellon University came up with ten secure coding practices. As simple as it may sound, these are quite effective to secure your hard-worked code:
Validate input:
This you should do from untrusted data sources. Input validation, if properly done, can get rid of most software vulnerabilities. Be wary of most external data sources such as network interfaces, command-line arguments, user-controlled files and environmental variables. 
Heed compiler warnings:
Code compiling should be done with the highest warning level for the compiler; remove warning with code modification. The additional security flaws should be detected and eliminated with static and dynamic analysis tools. 
Design & Architect for security policies:
Go for software architecture and design your software to enforce and execute a secure coding policy. For instance, if your system is designed for different privileges at various times, you should consider dividing it into separate intercommunicating subsystems, each provided with a suitable privilege set. 
A minimalist approach:
Complex designs are likely to increase their errors made in the configuration, implementation and use. Further, if you have a robust security mechanism, you needn’t worry about the assurance level.
Default deny: 
The access decisions should be permission-based instead of exclusion-based. This implies that access, by default, is denied and the conditions, identified by the protection scheme, grants access to permission.
Stick to the principle of least privilege: 
Every process should entail the least set of privileges needed to finish the job. Any elevated permission must only be accessed for the minimal amount of time needed to finish the privileged task. This can thwart any chances an attacker has to implement arbitrary code with elevated privileges.
Clean up data sent to other systems:
Clean up and sanitize all data that is passed to complex systems including commercial off-the-shelf (COTS) components, relational databases and command shells. Attackers can invoke functionalities left unused in these components via the use of the command, SQL or several other injection attacks. And we know quite well that this isn’t essentially an input validation issue as the complex subsystem that is being invoked has no understanding of the context in which a specific call is made. As the calling process has a fair understanding of the context, it can sanitize and clean up the data before the subsystem is invoked by it. 
Practice deep level defence:
Adopt multi-layered defensive strategies; therefore, if one layer is not good enough, another layer of defence should serve as a citadel against exploitable vulnerabilities and reduce the effects of a potential exploit. For instance, a combination of secure runtime environments and secure programming methods should likely reduce the probability of the vulnerabilities found in the code level at deployment time could be exploited in the operational environments. 

Use efficient QA techniques:
Effective QA techniques can be useful for eliminating and identifying vulnerabilities. Penetrating testing, source code audits and Fuzz testing should be included as part of an effective QA program. Secure reviews, if done independently, can result in more secure systems, because this can bring in an autonomous perspective; for instance, in determining and fixing invalid assumptions.

Deploy a sound and secure coding standard:
Stick to a secure coding techniques. Create and/or apply a secure coding standard for your intended development platform and language.