What makes a piece of software ‘high quality’? Some people might say it needs to have lots of features. Others may say it needs to be extremely reliable, something that never crashes. And others still might say all you need is a slick UI with satisfying animations. (Don’t let that third group near your dev team.)
But for most people, ‘security’ isn’t usually the first answer that pops up in their heads. Security has always been relegated to stepchild status, an afterthought that’s bolted on to the end product to get it to pass some compliance regulations.
In reality, an application that performs all its intended functions well cannot be considered ‘high-quality’ if it doesn’t also operate securely. Every microservice, every container, every last API can drastically affect how your application processes user data, opening up new channels for bad actors to sneak in and wreak havoc.
How then, can security not be part of the ‘intended experience’? To quote this report by CISA, “Security is not a luxury option but is closer to the standard every customer should expect without negotiating or paying more.”
To that end, a secure application isn’t one that has security features added to it at the end of the build, but one where the controls are baked into the product all the way from design and development, to deployment and production.
Watch our webinar on-demand: “Leveraging SemGrep and Static Analysis for Paved Roads and Secure Defaults”.
A product that’s considered ‘secure by design’ is one where the security implementation is deeply enmeshed in the structure of the software, where a lot of planning went into finding and fixing vulnerabilities at the earliest possible stage. That could be performing a static analysis (SAST) scan before each build to check the source code, or analyzing the list of third party components for insecure libraries, or testing the app during runtime with DAST.
Each of these confer their own benefits, but when these activities are performed as part of a CI/CD pipeline, where every step feeds into the next, the resulting stream of useful security data can not only make it easier for the developers to fix pressing security issues, but allow the security team to give actionable feedback.
Over time, incremental improvements in the pipeline can make for serious gains in efficiency, improved documentation, and most importantly, a much more secure product.
Secure-by-design is not to be confused with ‘Secure-by-default’, which refers to a product that is secure out of the box and doesn’t need to be configured by the customer. That means implementing controls like single sign-on (SSO), eliminating default passwords, etc.
Let’s look at some secure software development practices as recommended by CISA.
Watch our webinar on-demnad: “Leveraging SemGrep and Static Analysis for Paved Roads and Secure Defaults”.
A good place to start your secure-by-design journey is with the Secure By Design document by CISA, an in-depth exploration of secure development practices, pro-security business practices, and other useful suggestions on aligning your team and company towards a more security-centric approach.
If you want to learn more about applying secure-by-design practices in your SDLC, you should check out our upcoming webinar: ““Leveraging SemGrep and Static Analysis for Paved Roads and Secure Defaults”. Here, AppSecEngineer CEO Abhay Bhargav looks at how Semgrep can help you establish secure coding practices and enforce policy compliance across your codebase.
Over the course of 90 minutes, this live session will show you how to integrate static analysis seamlessly into your development workflow to enhance security and productivity. It’s free to attend, so tune in on 27th June, at 9AM PT!
Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.
Contact Support
help@appsecengineer.com
1603 Capitol Avenue,
Suite 413A #2898,
Cheyenne, Wyoming 82001,
United States
Contact Support
help@appsecengineer.com
68 Circular Road, #02-01, 049422, Singapore