![]() |
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Ensuring the security of an application is a constant and growing concern for development and infrastructure teams. The number of potential attacks and vulnerabilities in an application depends on many factors. The code, its dependencies and the application’s infrastructure all influence how secure it is. When a cloud application uses a microservice architecture, it will need more attention due to the added dependencies.
With that in mind, how do we reduce complexity to keep cloud applications more secure? In this article, we’ll explore DevSecOps, why it’s growing in organizations, and provide some tips for improving DevSecOps in practice.
DevOps is more about culture than technology. Likewise, DevSecOps is related to cultural behavior when it comes to security concerns and operations. Combining development, security and operations, DevSecOps is a set of practices designed to standardize security operations across the entire process of developing and deploying applications.
Using automated processes to check for security flaws in the pipeline is an example of DevSecOps in practice. Another is including different types of tests as part of the release process. The important thing here is to include security checks at every step, not just at runtime. There’s a cultural element as well, requiring a mind shift among those building the application.
Security flaws are expensive. They can destroy a company or its reputation. In the age of data, each security flaw discovered by an attacker could spell disaster. So finding them as soon as possible is essential to preventing breaches and mitigating this type of risk.
Today we have tools that check for dependencies and provide a list of known vulnerabilities. With this, developers can ensure that everything is updated before they submit the code, so that they don’t add a new violation.
When it comes to infrastructure with containers, it is easy to replicate production in a pen-testing environment. You can automate the process of creating an environment and executing the tests in each build. Investing in DevSecOps is definitely cheaper than disaster recovery. So why not use it?
Simply implementing DevSecOps is a big step toward preventing losses, and there are many different practices that can be used according to your context and needs. Some techniques, however, are common for any type of application. Below, we will discuss some basic techniques that you can put into practice to ease the daily work of your DevSecOps team.
Build generation is the best time to include a scan that checks to see if new vulnerabilities have been added. This scan should check the entire application, not just the new code. Adding this check to the pipeline will force developers to update and patch vulnerabilities in order for the pipeline to run. There are four types of verification, and it’s a good idea to try to include them all:
A good observability setup is not just for monitoring application health. It can also be helpful for identifying security issues. For example, a spike in an endpoint can be an attack. Therefore, you want to create intelligent alerts that combine information about access sources, failed access attempts, operating systems and databases.
Along with these alerts, you can add some predefined actions to prevent an attack from taking down your application. For example, try to figure out your app’s average usage and block or redirect access if you get an unexpected spike. But make sure that you’re on the same page with marketing and other departments so that you can properly prepare and change your limits when a spike is detected or predicted.
For security reasons, developers should not be able to access logs in high environments. But this lock can make it difficult to investigate a security issue.
Therefore, the development team needs to work closely with DevOps and DevSecOps. If the application has a security issue, it’s likely that the fix will come through a code change. With that in mind, prepare the production logs so your developers can access them if needed. Anonymize secret values and implement a temporary access policy that can be easily granted and quickly revoked.
If the logs can only be accessed through DevSecOps, it will take more time to identify and fix a security issue since the development team will need to request the logs many times to identify the problem. With a temporary access policy in place, they can get to work faster, and the DevSecOps team can focus on the investigation, rather than on providing logs to developers.
Keeping your app and your cloud environment safe is continuous work. Many new vulnerabilities emerge every day, and this can be frustrating for everyone involved in the software development process. Implementing processes to make it less painful is the key to not giving up on security. Automate as much as you can. Start small, define a security policy and a simple flow to deploy it, then evolve. Always keep striving to improve security across your cloud estate with agile DevOps security tools and best practices.
Further Reading