Companies are constantly searching for ways to deliver high-quality products quickly and efficiently. The evolution of DevOps revolutionized the industry by merging development and operations teams, breaking down silos, and fostering collaboration and communication.

However, as startups and businesses strive for agility and speed, security often falls by the wayside. This is where DevSecOps steps in - the integration of security practices into the DevOps framework.

In this article, we will explore the transition from DevOps to DevSecOps, the role of a DevSecOps engineer in a startup, and the importance of integrating security into the software development lifecycle.

Additionally, we will dive into the implementation of Dynamic Security Application Testing (DAST) within the continuous integration and continuous delivery (CI/CD) pipeline. By shifting left and making security a priority from the very beginning, startups can enhance their business value, protect their users, and deliver secure and reliable software.

An Overview of DevOps

From Ops to DevOps

Initially, before the advent of DevOps, the traditional siloed methods of software development were in place. The development and operational teams worked in isolation, leading to several issues, such as longer development cycles, less collaboration, poor quality output, and slower time to market. The development team was tasked with writing the code while the operations team was responsible for its deployment and maintenance. Any problems arising in production were thrown over the wall to the operations team without much communication and collaboration between the two teams.

The consequences of such a disjointed and disordered approach were disastrous for companies, leading to conflicts, slow product releases, and unsatisfied customers. This was more damaging in the case of startups, as they are expected to be agile, flexible, and faster in their operations.

Acknowledging the issues inherent in these traditional methodologies, the IT industry began seeking out efficient ways to improve the overall process. This pursuit led to the evolution of DevOps, a practice that amalgamates software development and IT operations. DevOps heralded a cultural shift towards a more collaborative and communicative environment, breaking down the walls between the development and operations teams.

Not only did DevOps mitigate the problems posed by the traditional model, but it also introduced a host of additional benefits that have now come to be considered essential for startups. Through continuous integration, continuous deployment, automated testing, and infrastructure as code, DevOps has enabled startups to reduce time to market, enforce reliability, increase the speed and quality of releases, and maintain a high frequency of deployments.

With the numerous advantages brought by the DevOps model, startups were no longer stuck in the rut of delayed deliveries and slow response time. Yet, as they chugged along the path of efficiency and speed, one aspect remained somewhat neglected - that's security.

DevOps vs DevSecOps

Why do we shift from the DevOps to DevSecOps?

Traditionally, security was a separate consideration, often addressed at the end of the software development lifecycle. This created a tension between speed and security, with teams tempted to rush toward deployment, prioritizing speed over security. Unfortunately, in our digital age, security can't be an afterthought.

Less than 5 years after the embrace of DevOps, the IT landscape began shifting to DevSecOps. The core idea of DevSecOps is to 'shift security to the left', i.e., equipping even the early stages of software development with robust security checks and balances.

This eliminates the last-minute scramble to tie loose ends and allows startups to find vulnerabilities early when they're easier and less costly to fix.

So, startups began shifting to DevSecOps, not only to keep up with their fast-paced decision-making and often quicker development cycles but more importantly, as a business-essential move to protect their company's and customers' data right from the start.

By integrating DevOps and security, DevSecOps works with Devs to provide remediation actions instead of long lists of problems. Thus, shifting from DevOps to DevSecOps has been a tactical move for startups, enhancing their business value and gaining trust from their users. You can learn more about the link between DevOps and shift left here.

Understanding the role of a DevSecOps in a startup

In this chapter, we will walk through some examples of challenges that DevSecOps handles and why this is an important step forward to embrace this philosophy.

Integrating security into the software life cycle

One of the primary challenges for a DevSecOps engineer is fitting security into the entire software development life cycle.

Traditional approaches treated security as a separate entity that would come into play after the development process was complete. However, in DevSecOps, security becomes an integral part of every step of the software development process.

But in a DevSecOps model, the DevSecOps engineer has to drive the adoption of security processes right from planning, coding, and testing to release, deployment, and monitoring. This might involve automating security controls, setting up vulnerability and compliance policies, or even training teams on security best practices.

Shifting these technologies through the Developers' landscape not only creates more secure products but also improves their quality of life.

In short, integrating security into the software life cycle underlines the core idea of DevSecOps - simpler security is better for both Devs and Ops. The DevSecOps engineer ensures that security isn't just a reaction to threats, but a proactive, preventative, and continuous approach throughout the development process.

Keeping up with rapid releases

In a fast-evolving scenario, where new code commits are happening all the time, the role of a DevSecOps engineer involves ensuring that every version upgrade or feature update maintains a high level of security. Often, this means staying ahead of the game: foreseeing the security implications of changes, testing new functionalities for potential vulnerabilities, and ensuring that changes don't inadvertently weaken the existing security infrastructure.

However, it doesn’t stop once the release is rolled out. After deployment, they must continually monitor the application for any security issues that may have slipped through the cracks. This involves responding to new vulnerabilities as they are discovered and ensuring that patches and updates are promptly rolled out to the clients.

Keeping up with rapid releases is not just about quick reactions. It’s about creating a culture where security is baked into every code commit and every deployment. It’s about making sure that even in the race to innovate, startups don’t have to compromise their client’s trust and their reputation.

For sure, this could be challenging but the results: secure, reliable, and consistent software, are worth it. So, thank a DevSecOps engineer for that!

A practical example: Deploying DAST in CI/CD

Continuous Integration and Continuous Delivery, often termed CI/CD, is at the heart of modern DevOps practices. It's all about automating the stages of app development, from integrating code changes to delivering and deploying updates to production.

In Continuous Integration, developers merge their code changes into a central repository, followed by automatic builds, testing, and deployment. This happens multiple times a day, improving software quality and reducing the time to deploy: if the pipeline is green, it means that all tests succeed and the app is ready for release.

The second part is Continuous Delivery. It ensures that we can release new changes to customers quickly and sustainably. It involves automated testing beyond unit tests (like integration tests, performance tests, and others) to verify if the updates will not break the production system. Most importantly, eases the deployment workflow with a simple click of a button: no need to call the person who knows how to SSH to the production VM to run a shell script that does some magic.

But let's get back to how DevSecOps fits into this. Remember our friend, security? DevSecOps brings it right into the mix of CI/CD. It involves integrating security checks and tests into the CI/CD pipeline, essentially introducing continuous security on top of CI/CD.

Automated security scans are run at every stage of development. Vulnerabilities and flaws are detected and fixed early in the software development lifecycle, reinforcing the principle of 'shifting security to the left'. By automating security testing, DevSecOps ensures that security is as continuous as integration and delivery.

In essence, DevSecOps leverages the principles and benefits of CI/CD and takes it a step further by making security an integral part of the pipeline. So, you get a faster, more reliable, and more secure software development process. Sounds like a win-win-win, right?

To take a practical example: you don't want to discover secrets committed to your code right? But do you want to test it after production deployment, before it, after each merge on the dev branch, in merge requests, or right into the developers' computers using pre-commit hooks like Semgrep? Shift Left is not only improving security, it's also providing developers tools to not think about security but help them not make mistakes.

Dynamic Security Application Testing (DAST)

As part of the DevSecOps team, the primary goal is to ensure that no security vulnerabilities make it to production. One of the top strategies for doing this job is DAST or Dynamic Application Security Testing.

Unlike its static counterpart (SAST), DAST evaluates the application from the outside while it's running, just as a real attacker would. Think of it as a simulated hacker, working hard to spot weaknesses. It performs penetration testing and detects security vulnerabilities that could be exploited. It’s particularly good at finding execution flow flaws and runtime issues that can't be spotted by static testing.

DAST can expose issues like insecure server configurations, software bugs, injection attacks, and more, allowing us to fix them before they become a potential threat. The beauty of DAST is that it doesn’t require code access and can immediately start testing.

Within DevSecOps, DAST becomes even more essential. As we constantly integrate new code and deliver updates, DAST provides automated, continuous testing targeting these changes. The ultimate goal? To ensure that every release improves the application while maintaining robust security standards.

So, DAST remains one of the most DevSecOps trusted tools, ensuring that every line of code is as secure as possible.

How we run DAST in CI/CD at Escape

At Escape, we want to always keep providing value to our customers by deploying our work to production multiple times a day. To do so, we want to be sure that the QA environment is always secure as a flaw in it may be in production in less than 12 hours.

At Escape our job is to help companies to shift left with the DevSecOps philosophy. We are creating a DAST that can help Security teams to be aware of vulnerabilities but also help developers to solve them. Escape allows you to create API documentation automatically after discovering exposed API services, so you'll be able to get started with your DAST scans quickly. You can see reach out to see it in action on your domain.

Multiple actions have been set up to ensure deployment quality like container image scanning but the most important piece is the "Escape on Escape" scan. We use GitLab CI to run a scan on our QA environment each time a commit is made into it (but this action is available for any CI/CD, read the Escape docs).

Escape:
  allow_failure: true
  variables:
    ESCAPE_APPLICATION_ID: <RETRACTED>
    ESCAPE_API_KEY: <RETRACTED>
    TIMEOUT: 3600
  image: node:alpine
  before_script:
    - npm install -g @escape.tech/action
  script:
    - escape-action
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "escape"
    - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "QA"

With this job, we can ensure that QA is scanned a least once a day (we have scheduled a daily pipeline) and also after each update.

This has helped us multiple times by not only detecting some server configuration errors but also pointing to business logic race conditions as the scanner doesn't only assess vulnerabilities but uses the application to find not only security flaws but all types of bugs.

Conclusion

As we wrap up, it's hard to tamp down the excitement we feel about the incredible transformation that DevSecOps has brought about, especially for startups like ours.

Thinking about it, the seamless fusion of development, operations, and security isn’t just the future of the software industry, it's the present!

In making the shift from DevOps to DevSecOps, we're taking a giant leap towards enhanced efficiency and secure code. By embracing practices such as CI/CD and incorporating DAST, we've created an environment where code releases are not just fast and frequent, but also reliable and secure.

So here’s to more code commits, more deploys, more secure software, and ever-evolving DevSecOps practices!

Let’s keep pushing the boundaries of what's possible when Devs, Ops, and Sec embrace and unite their work.

💡Want to learn more about DevSecOps practices? Check out the following articles:

• Top 7 DevSecOps Best Practices
• DevSecOps 101 part 1: Software Component Analysis (SCA)
• DevSecOps 101 Part 2: Detecting Insecure Source Code 
• DevSecOps 101 Part 3: Scanning Live Web Applications with Nuclei
• DevSecOps 101 Part 4: Scanning Docker Images With Trivy
• How to automate and secure deployment within GitLab CI with Syft and Grype