The Secure Developer: talking DevSecOps in Azure with Microsoft’s Victoria Almazova

Written by:
Hayley Denbraver
Hayley Denbraver

September 26, 2019

0 mins read

In February of this year, Snyk launched a new educational, vendor-neutral, and security-focused community, The Secure Developer. Snyk wants to help developers adopt a security mindset throughout their development process and The Secure Developer community is the place where you can do just that; a place to learn security best practices from experts in an approachable, positive way.

Over the past seven months, The Secure Developer has hosted virtual sessions every two weeks with topics ranging from microservice security to OWASP top 10 proactive controls.

If you are skeptical of the value of a virtual session, allow me to give you a quick taste by going over a recent Secure Developer session. Hopefully, this will convince you to join us for our next virtual session.

DevSecOps in Azure with Microsoft’s Victoria Almazova

Victoria Almazova is a Cloud Solution Architect with Microsoft. Her job involves helping people plan, architect, and deploy their projects to Azure cloud. She keeps security in mind throughout this process and that is exactly what she talked about in her recent session.Victoria walked us through her processes for:

  • implementing Azure security on the subscription level

  • developing secure applications

  • securely deploying your applications

  • periodically scanning production for compliance and security

When DevOps first became popular, Victoria was skeptical of the concept because it seemed to elbow out security. Eventually, she came around to the idea of DevOps as it presented an opportunity to integrate security in a more holistic way. Victoria defined DevOps as the union of people, processes, and technology that enables continuous delivery of value to end users. Whether a person likes the buzzword that is “DevSecOps” or not, security has indeed the opportunity to participate in the entire DevOps process, from beginning to end,  making the final product even more valuable.

Integrating security into a DevOps process can seem overwhelming, so Victoria provides us with a few starting points.

Infrastructure can be a low hanging fruit. Victoria recommends thinking about your Azure subscriptions in ‘per project’ and ‘per environment’ terms. This helps ensure proper permissions and settings for each project and environment. It is also important that policies are transparent and proactive. What’s more, Victoria suggested that the Azure Security Center be employed from day one.

To round out her infrastructure recommendations, Victoria strongly believes taking an Infrastructure as Code (IaC) approach is crucial. In case you are not familiar with the term, IaC is the management of infrastructure in a descriptive model, using the same versioning as DevOps teams use for source code. The IaC model fights environment drift and produces consistent environments.

Victoria’s final secure infrastructure tip is to only allow production environments to be updated through the Continuous Integration/Continuous Delivery (CI/CD) pipeline; never through a manual process. The CI/CD pipeline is at the heart of security initiatives. As Victoria moved on to discussing application security, she walked the community through how this intersects with different parts of the CI/CD pipeline. Victoria defined the steps of the CI/CD pipeline to include the following:

  1. Pre-commit

  2. Commit (CI)

  3. Acceptance (CD)

  4. Production

  5. Operations

Each of the above areas can be enhanced with security practices, which are outlined in the following sections.


The pre-commit stage is where a developer is writing new code or making changes to existing code. Any investment in security at this stage will pay off later as it is easier to make changes at this point in the pipeline. It is an opportune time to do some threat modeling, to use a security IDE plugin, to abide by your teams’ secure coding standards, and to do peer review.

Commit (CI)

At the commit stage, you can set up a number of processes to run automatically. Security considerations at this point in the CI/CD pipeline include static code analysis, security unit tests, and dependency management.


Relevant security considerations at the acceptance stage include IaC, security scanning, cloud configuration, and security acceptance testing. These tests can take place on a QA/Stage environment before things are pushed to production.


Security procedures that provide value in production include security smoke tests, configuration checks, and penetration testing.


In the operations stage, the ongoing processes of continuous monitoring, threat intelligence, penetration testing, and blameless postmortems help reinforce a good security posture and culture.

The Secure Developer

Victoria wrapped up her session with a demo and a Q&A. I encourage you to watch the entire presentation here. I appreciated Victoria’s perspective on the numerous ways a developer can up their security game, whether they are deploying a project to the Azure Cloud or another solution.

The Secure Developer Community is committed to bringing excellent speakers like Victoria Almazova to both our virtual sessions and our podcast. If you are interested in learning more about all aspects of security, please consider joining the community. We would love to see you.

Posted in:DevSecOps
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer’s toolkit.

Start freeBook a live demo

© 2024 Snyk Limited
Registered in England and Wales