<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: andre aliaman</title>
    <description>The latest articles on Forem by andre aliaman (@iilness2).</description>
    <link>https://forem.com/iilness2</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F274834%2Fba686a6f-2548-4437-b0cd-eaa9de3c3714.png</url>
      <title>Forem: andre aliaman</title>
      <link>https://forem.com/iilness2</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/iilness2"/>
    <language>en</language>
    <item>
      <title>My Perspective on AWS Security Hub for DevSecOps</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Wed, 31 Dec 2025 09:58:37 +0000</pubDate>
      <link>https://forem.com/aws-builders/my-perspective-on-aws-security-hub-for-devsecops-1bd</link>
      <guid>https://forem.com/aws-builders/my-perspective-on-aws-security-hub-for-devsecops-1bd</guid>
      <description>&lt;p&gt;In my previous article, I shared my perspective on &lt;a href="https://dev.to/iilness2/my-perspective-on-amazon-inspectors-2025-updates-for-devsecops-218m"&gt;Amazon Inspector's 2025 updates&lt;/a&gt; and how it now covers most areas in DevSecOps. At the end of that article, I mentioned Security Hub as the place where all these findings come together.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;So why am I talking about Security Hub?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Because from my perspective, it's the central piece that ties everything together.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Problem &amp;amp; Why Security Hub Helps
&lt;/h2&gt;

&lt;p&gt;In today's world, we need to comply with various standards — whether it's &lt;a href="https://dev.to/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m"&gt;NIST guidelines&lt;/a&gt; that I discussed before, CIS Benchmarks, or PCI-DSS for those handling payment data. With all these compliance requirements, a lot of security models and stages have been introduced lately.&lt;/p&gt;

&lt;p&gt;What does this mean for us? More dashboards to monitor.&lt;/p&gt;

&lt;p&gt;Especially for people who work on operations, this becomes overwhelming. You have findings from Inspector, alerts from GuardDuty, issues from IAM Access Analyzer, and the list goes on. Jumping between consoles just to get a complete picture of your security posture is not efficient.&lt;/p&gt;

&lt;p&gt;This is where Security Hub helps.&lt;/p&gt;

&lt;p&gt;Security Hub acts as a single place where all your security findings are aggregated. Instead of checking multiple dashboards, you get one consolidated view. From my experience, this saves a lot of time — especially when you need to report the overall security status to stakeholders or during audits.&lt;/p&gt;

&lt;p&gt;What I find useful is the integration with other AWS security tools. Inspector findings for vulnerabilities, GuardDuty for threat detection, Macie for data security — all flow into Security Hub automatically. If you're managing multiple AWS accounts in an organization, the cross-account visibility is also helpful. You can see the security posture across all accounts from one place.&lt;/p&gt;

&lt;p&gt;For compliance, Security Hub also provides automated checks against standards like CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. This helps when you need to demonstrate compliance during audits.&lt;/p&gt;

&lt;h2&gt;
  
  
  What It Doesn't Solve
&lt;/h2&gt;

&lt;p&gt;Being honest here — Security Hub is great for aggregating findings, but it doesn't cover everything.&lt;/p&gt;

&lt;p&gt;For areas like DAST (Dynamic Application Security Testing), you still need to look elsewhere. As I mentioned in my &lt;a href="https://dev.to/iilness2/practical-way-for-security-assestment-in-aws-with-prowler-4i85"&gt;Prowler article&lt;/a&gt;, there are other tools that complement what AWS provides natively.&lt;/p&gt;

&lt;p&gt;Security Hub is the central piece, but it's not the only piece.&lt;/p&gt;

&lt;h2&gt;
  
  
  Closing
&lt;/h2&gt;

&lt;p&gt;From my perspective as someone working in DevSecOps, Security Hub brings value by reducing the complexity of monitoring multiple security tools. In a world where compliance requirements keep growing, having one place to see everything matters.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>devops</category>
      <category>security</category>
      <category>cybersecurity</category>
    </item>
    <item>
      <title>My Perspective on Amazon Inspector's 2025 Updates for DevSecOps</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Wed, 31 Dec 2025 09:56:51 +0000</pubDate>
      <link>https://forem.com/aws-builders/my-perspective-on-amazon-inspectors-2025-updates-for-devsecops-3pf4</link>
      <guid>https://forem.com/aws-builders/my-perspective-on-amazon-inspectors-2025-updates-for-devsecops-3pf4</guid>
      <description>&lt;h2&gt;
  
  
  Introduction
&lt;/h2&gt;

&lt;p&gt;Back in early 2024, I wrote about &lt;a href="https://dev.to/iilness2/latest-improvements-in-amazon-inspector-from-reinvent-2023-from-my-perspective-291n"&gt;My Perspective on the Latest Improvements in Amazon Inspector from re:Invent 2023&lt;/a&gt;. At that time, AWS focused more on Lambda code scanning and agentless EC2 scanning.&lt;/p&gt;

&lt;p&gt;Fast forward to 2025, and Amazon Inspector has evolved significantly. As a DevSecOps practitioner, I put my eyes on all the new features that they bring.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;So what's changed in the past two years?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;In this article, I want to share what's new in Amazon Inspector for 2025 and how these updates benefit us as DevSecOps Engineers.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;em&gt;What's New in Amazon Inspector 2025?&lt;/em&gt;
&lt;/h2&gt;

&lt;p&gt;Let me walk you through the key updates since my last article.&lt;/p&gt;

&lt;h3&gt;
  
  
  Enhanced Container Scanning Engine (February 2025)
&lt;/h3&gt;

&lt;p&gt;AWS upgraded the engine that powers container image scanning for Amazon ECR. This update provides better dependency detection, more comprehensive vulnerability findings, and automatic re-evaluation of existing resources.&lt;/p&gt;

&lt;p&gt;In my 2023 article, I talked about ECR scanning capabilities. The 2025 engine upgrade makes those scans more accurate and thorough. The best part? This upgrade happened automatically. You don't need to do anything.&lt;/p&gt;

&lt;h3&gt;
  
  
  Code Security (GA - June 2025)
&lt;/h3&gt;

&lt;p&gt;This is the biggest update in my opinion. In my 2023 article, I talked about how Inspector could scan Lambda functions and container images. Now, it can scan your &lt;strong&gt;source code&lt;/strong&gt; directly — before you even build anything.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Why is this important?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;From my experience, finding a vulnerability in code costs 10x less than finding it in production. The earlier you catch the issue, the cheaper it is to fix.&lt;/p&gt;

&lt;p&gt;Code Security includes SAST for scanning your source code, SCA for scanning third-party dependencies, and IaC scanning for your Terraform and CloudFormation templates. It also has native GitHub and GitLab integration — findings appear directly in your Pull Requests.&lt;/p&gt;

&lt;h3&gt;
  
  
  Organization-wide Management (November 2025)
&lt;/h3&gt;

&lt;p&gt;If you've ever tried to enable Amazon Inspector across multiple AWS accounts, you know the pain. In my previous article, I mentioned how Inspector integrates with AWS Organizations. But back then, you still had to configure each account.&lt;/p&gt;

&lt;p&gt;Not anymore. AWS introduced Organization-wide Management using AWS Organizations policies. Now, one policy covers all accounts, new accounts get auto-enrollment, and you have a consistent baseline across your organization.&lt;/p&gt;

&lt;p&gt;As a DevSecOps Engineer, this saves me hours of setup and ensures no account is left unprotected.&lt;/p&gt;

&lt;h3&gt;
  
  
  Security Hub Integration (re:Invent 2025 - December)
&lt;/h3&gt;

&lt;p&gt;Amazon Inspector findings now integrate seamlessly with AWS Security Hub. Security Hub correlates signals from Inspector, GuardDuty, and Macie to provide near real-time risk analytics.&lt;/p&gt;

&lt;p&gt;I'll cover Security Hub in detail in my next article — it deserves its own deep dive.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;em&gt;What Are the Benefits as DevSecOps Engineer?&lt;/em&gt;
&lt;/h2&gt;

&lt;p&gt;With this improvement, as a DevSecOps Engineer, I think it's covering the main areas in DevSecOps now.&lt;/p&gt;

&lt;p&gt;As DevSecOps, we also focus on security. And I always felt the gap where when we're doing implementation in AWS, we always need to look at third-party tools for covering SAST, SCA, even parts like IaC scanning and container scanning. We had to set up separate tools like Snyk, Checkov, or Trivy, and then figure out how to integrate them with our AWS environment.&lt;/p&gt;

&lt;p&gt;But with this improvement, Inspector now covers all these parts. SAST for scanning source code, SCA for scanning dependencies, IaC scanning for Terraform and CloudFormation, and container scanning for ECR images.&lt;/p&gt;

&lt;p&gt;The only thing missing is DAST (Dynamic Application Security Testing) — we still need to look elsewhere for that. For DAST, I find Prowler is an interesting tool which you can read in my article &lt;a href="https://dev.to/iilness2/practical-way-for-security-assestment-in-aws-with-prowler-4i85"&gt;Practical Way for Security Assessment in AWS with Prowler&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;So now we can have a complete DevSecOps chain that covers all my application supply chain — from code to runtime.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;What about if you're already using AWS?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;This is where Inspector really shines. If you're already on AWS, the integration is seamless. ECR automatically scans on image push. CodePipeline and CodeBuild have native integration. EventBridge can trigger automated workflows. Organizations let you manage multiple accounts with a single policy. And CloudTrail provides audit logging for compliance.&lt;/p&gt;

&lt;p&gt;You don't need to set up separate tools and figure out how to connect them. It's already integrated with your AWS environment.&lt;/p&gt;

&lt;p&gt;And speaking of compliance — in my article about &lt;a href="https://dev.to/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m"&gt;NIST Guidelines&lt;/a&gt;, I discussed how organizations need to follow security frameworks. This is the best part — Inspector also directly supports generating SBOM in CycloneDX and SPDX formats. This part, we can combine with CloudTrail for audit trails.&lt;/p&gt;

&lt;p&gt;With CycloneDX and SPDX formats, you can also integrate with other tools that support the format as well, like GitLab. So you're not locked into AWS — you have flexibility to use SBOM data across your toolchain.&lt;/p&gt;

&lt;h2&gt;
  
  
  Conclusion
&lt;/h2&gt;

&lt;p&gt;Since I wrote my 2023 article, a lot has improved in Amazon Inspector. The 2025 updates — especially Code Security and Organization-wide Management — have transformed Inspector from a vulnerability scanner into a comprehensive DevSecOps platform.&lt;/p&gt;

&lt;p&gt;From my perspective as a DevSecOps Engineer, Inspector now covers most of what I need. And if you're already using AWS, the integration is seamless.&lt;/p&gt;

&lt;p&gt;In my next article, I'll dive into AWS Security Hub and how it brings all your security findings together into a single view. Stay tuned!&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below. So, I know about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>devsecops</category>
      <category>cicd</category>
      <category>security</category>
    </item>
    <item>
      <title>Implementing Container Signing in Your CI/CD Pipeline: A DevSecOps Approach with AWS</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Wed, 31 Dec 2025 09:42:56 +0000</pubDate>
      <link>https://forem.com/aws-builders/implementing-container-signing-in-your-cicd-pipeline-a-devsecops-approach-with-aws-268d</link>
      <guid>https://forem.com/aws-builders/implementing-container-signing-in-your-cicd-pipeline-a-devsecops-approach-with-aws-268d</guid>
      <description>&lt;h2&gt;
  
  
  Introduction
&lt;/h2&gt;

&lt;p&gt;This article is part of my ongoing series about DevOps and DevSecOps practices. If you've been following along, you may have read my previous articles on &lt;a href="https://dev.to/iilness2/perspectives-on-the-evolution-of-devsecops-engineering-based-on-from-my-experiences-21me"&gt;the evolution of DevSecOps&lt;/a&gt; and &lt;a href="https://dev.to/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m"&gt;how NIST guidelines enhance software security&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;In my NIST article, I discussed how security should be embedded into every stage of the Software Development Life Cycle (SDLC). I also mentioned tools like AWS CodeBuild, CodePipeline, and SecurityHub as part of a DevSecOps pipeline. Today, I want to add another critical piece to that puzzle: &lt;strong&gt;Container Signing&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;As someone who has been working with CI/CD pipelines for several years, I've noticed that container signing is often the "forgotten step" in many pipelines. Teams invest heavily in SAST, DAST, and SCA scanning, but skip image signing because it used to be complex to implement. With AWS's new Managed Signing feature released in November 2025, that excuse no longer holds.&lt;/p&gt;

&lt;p&gt;Let me walk you through why container signing matters in DevSecOps and how to integrate it into your CI/CD pipeline.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why Container Signing Matters in DevSecOps
&lt;/h2&gt;

&lt;p&gt;In my previous article about DevSecOps evolution, I explained the concept of "shifting security left" — integrating security practices early in the development process rather than treating it as an afterthought. Container signing is a perfect example of this principle in action.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;What Problem Does It Solve?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Think about your current CI/CD pipeline. You probably have something like this:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5p7dliyne0rkuzsahwht.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5p7dliyne0rkuzsahwht.png" alt="CICD Old Way" width="800" height="173"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;But here's a question I often ask teams: &lt;strong&gt;How do you know the image you're deploying is the same image that passed your security scans?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Between your build stage and deployment stage, several things could go wrong:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Someone could push a modified image to your registry&lt;/li&gt;
&lt;li&gt;A compromised CI/CD runner could inject malicious code&lt;/li&gt;
&lt;li&gt;An attacker could perform a man-in-the-middle attack&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Without container signing, you're essentially trusting that nothing bad happened between your build and deploy stages. In DevSecOps, we call this a &lt;strong&gt;supply chain risk&lt;/strong&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  The DevSecOps Pipeline: Where Container Signing Fits
&lt;/h2&gt;

&lt;p&gt;Let me show you where container signing fits in a proper DevSecOps pipeline. This builds on the pipeline I discussed in my NIST article:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8ls12x4q7ku28r6ii27h.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8ls12x4q7ku28r6ii27h.png" alt="DevSecOps Pipeline" width="800" height="264"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Notice the &lt;strong&gt;SIGN&lt;/strong&gt; and &lt;strong&gt;VERIFY&lt;/strong&gt; stages. These are what most pipelines are missing. Let me explain each:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;SIGN Stage&lt;/strong&gt;: After your image passes all security scans (SAST, DAST, SCA, vulnerability scanning), it gets signed. This signature proves that the image has been vetted and approved for deployment.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;VERIFY Stage&lt;/strong&gt;: Before deployment, an admission controller checks the signature. If the signature is invalid or missing, the deployment is blocked. No exceptions.&lt;/p&gt;

&lt;p&gt;This approach aligns with what NIST calls "verifying the integrity of software components" — one of the key recommendations I highlighted in my previous article.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Old Way vs The New Way
&lt;/h2&gt;

&lt;p&gt;Before we dive into implementation, let me share why container signing was often skipped in CI/CD pipelines.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;The Old Way (Before November 2025)&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;To sign containers, you had to:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Install Notation CLI on your build server&lt;/li&gt;
&lt;li&gt;Install AWS Signer plugin&lt;/li&gt;
&lt;li&gt;Configure authentication between Notation and ECR&lt;/li&gt;
&lt;li&gt;Manage signing keys and certificates&lt;/li&gt;
&lt;li&gt;Add multiple commands to your buildspec.yml&lt;/li&gt;
&lt;li&gt;Handle token refresh (tokens expire after 12 hours)&lt;/li&gt;
&lt;li&gt;Troubleshoot cryptographic errors&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;For teams already juggling complex pipelines, this was too much overhead. I've seen many teams evaluate container signing and decide "we'll implement it later" — and later never comes.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;The New Way (AWS Managed Signing)&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;With AWS Managed Signing, the process becomes:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Create a signing profile (one-time setup)&lt;/li&gt;
&lt;li&gt;Create a signing rule in ECR (one-time setup)&lt;/li&gt;
&lt;li&gt;Push your image — it's automatically signed&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;No changes to your buildspec.yml. No additional tools to install. No keys to manage.&lt;/p&gt;

&lt;p&gt;This is the kind of simplification that makes DevSecOps adoption realistic for teams of all sizes.&lt;/p&gt;

&lt;h2&gt;
  
  
  Setting Up Container Signing in Your CI/CD Pipeline
&lt;/h2&gt;

&lt;p&gt;Let me walk you through how to integrate container signing into your existing AWS CI/CD pipeline.&lt;/p&gt;

&lt;h3&gt;
  
  
  Prerequisites
&lt;/h3&gt;

&lt;p&gt;Before we start, you should have:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;An existing CI/CD pipeline using CodePipeline and CodeBuild&lt;/li&gt;
&lt;li&gt;Container images stored in Amazon ECR&lt;/li&gt;
&lt;li&gt;Basic understanding of IAM permissions&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  Step 1: Create an AWS Signer Signing Profile
&lt;/h3&gt;

&lt;p&gt;The signing profile defines how your images will be signed. Think of it as a template for your signatures.&lt;/p&gt;

&lt;p&gt;Go to AWS Signer in the console:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Click &lt;strong&gt;Create signing profile&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Select &lt;strong&gt;Notation for container registries&lt;/strong&gt; as the platform&lt;/li&gt;
&lt;li&gt;Enter a profile name (e.g., &lt;code&gt;production-container-signing&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;Set the signature validity period (I recommend starting with the default 135 months)&lt;/li&gt;
&lt;li&gt;Click &lt;strong&gt;Create&lt;/strong&gt;
&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;em&gt;Pro Tip&lt;/em&gt;: Create separate signing profiles for different environments. I typically use:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;dev-container-signing&lt;/code&gt; for development&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;staging-container-signing&lt;/code&gt; for staging&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;production-container-signing&lt;/code&gt; for production&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This allows you to track which environment an image was approved for.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 2: Configure ECR Managed Signing
&lt;/h3&gt;

&lt;p&gt;Now, tell ECR to automatically sign images when they're pushed.&lt;/p&gt;

&lt;p&gt;In the ECR console:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Go to &lt;strong&gt;Private registry&lt;/strong&gt; → &lt;strong&gt;Features &amp;amp; settings&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Under &lt;strong&gt;Managed Signing&lt;/strong&gt;, click &lt;strong&gt;Configure&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Click &lt;strong&gt;Create rule&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Select your signing profile from Step 1&lt;/li&gt;
&lt;li&gt;Add a repository filter (e.g., &lt;code&gt;prod-*&lt;/code&gt; to sign all production repositories)&lt;/li&gt;
&lt;li&gt;Click &lt;strong&gt;Create&lt;/strong&gt;
&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;That's it for the signing setup. Your images will now be automatically signed when pushed to matching repositories.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 3: Update Your CI/CD Pipeline
&lt;/h3&gt;

&lt;p&gt;Here's the beauty of AWS Managed Signing: &lt;strong&gt;you don't need to change your buildspec.yml&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;Your existing buildspec probably looks something like this:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight yaml"&gt;&lt;code&gt;&lt;span class="na"&gt;version&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="m"&gt;0.2&lt;/span&gt;

&lt;span class="na"&gt;phases&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
  &lt;span class="na"&gt;pre_build&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="na"&gt;commands&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;echo Logging in to Amazon ECR...&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $ECR_REGISTRY&lt;/span&gt;

  &lt;span class="na"&gt;build&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="na"&gt;commands&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;echo Building Docker image...&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;docker build -t $IMAGE_NAME:$IMAGE_TAG .&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;docker tag $IMAGE_NAME:$IMAGE_TAG $ECR_REGISTRY/$IMAGE_NAME:$IMAGE_TAG&lt;/span&gt;

  &lt;span class="na"&gt;post_build&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="na"&gt;commands&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;echo Pushing to ECR...&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;docker push $ECR_REGISTRY/$IMAGE_NAME:$IMAGE_TAG&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;With managed signing enabled, the signing happens automatically during &lt;code&gt;docker push&lt;/code&gt;. No additional commands needed.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 4: Implement Signature Verification
&lt;/h3&gt;

&lt;p&gt;Signing is only half of the equation. To complete the security chain, you need to verify signatures before deployment.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;For Amazon EKS&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;If you're using EKS, you can implement verification using admission controllers like Kyverno or Ratify. These controllers intercept pod creation requests and verify the container image signature before allowing deployment.&lt;/p&gt;

&lt;p&gt;Here's a simple example of what a Kyverno policy might look like:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight yaml"&gt;&lt;code&gt;&lt;span class="na"&gt;apiVersion&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;kyverno.io/v1&lt;/span&gt;
&lt;span class="na"&gt;kind&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;ClusterPolicy&lt;/span&gt;
&lt;span class="na"&gt;metadata&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
  &lt;span class="na"&gt;name&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;verify-container-signatures&lt;/span&gt;
&lt;span class="na"&gt;spec&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
  &lt;span class="na"&gt;validationFailureAction&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;Enforce&lt;/span&gt;
  &lt;span class="na"&gt;background&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="kc"&gt;false&lt;/span&gt;
  &lt;span class="na"&gt;rules&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="na"&gt;name&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;verify-signature&lt;/span&gt;
      &lt;span class="na"&gt;match&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
        &lt;span class="na"&gt;any&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
        &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="na"&gt;resources&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
            &lt;span class="na"&gt;kinds&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
              &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;Pod&lt;/span&gt;
      &lt;span class="na"&gt;verifyImages&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="na"&gt;imageReferences&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
        &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s2"&gt;"&lt;/span&gt;&lt;span class="s"&gt;*.dkr.ecr.*.amazonaws.com/*"&lt;/span&gt;
        &lt;span class="na"&gt;required&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="kc"&gt;true&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;This policy enforces that all images from ECR must have a valid signature. If an unsigned image is deployed, the pod creation will be rejected.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;For Amazon ECS&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;For ECS, you can use service lifecycle hooks with Lambda to verify signatures before deployment. The Lambda function runs during the PRE_SCALE_UP phase, checking the signature before any containers are started.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 5: Enable Audit Logging
&lt;/h3&gt;

&lt;p&gt;As I mentioned in my NIST article, traceability is crucial for compliance. AWS CloudTrail automatically logs all signing operations, giving you a complete audit trail.&lt;/p&gt;

&lt;p&gt;Make sure CloudTrail is enabled in your account, and you'll have records of:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Who pushed the image&lt;/li&gt;
&lt;li&gt;When it was signed&lt;/li&gt;
&lt;li&gt;Which signing profile was used&lt;/li&gt;
&lt;li&gt;The signature details&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This information is invaluable for security audits and incident response.&lt;/p&gt;

&lt;h2&gt;
  
  
  Connecting to Your DevSecOps Toolchain
&lt;/h2&gt;

&lt;p&gt;Container signing doesn't exist in isolation. It's part of a broader DevSecOps strategy. Here's how it connects to other AWS security services I've discussed in my previous articles:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Stage&lt;/th&gt;
&lt;th&gt;AWS Service&lt;/th&gt;
&lt;th&gt;Purpose&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Code Quality&lt;/td&gt;
&lt;td&gt;CodeGuru&lt;/td&gt;
&lt;td&gt;Identify code issues early&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Vulnerability Scan&lt;/td&gt;
&lt;td&gt;Amazon Inspector&lt;/td&gt;
&lt;td&gt;Find CVEs in your images&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;Image Signing&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;AWS Signer + ECR&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;Prove image authenticity&lt;/strong&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Secret Management&lt;/td&gt;
&lt;td&gt;Secrets Manager&lt;/td&gt;
&lt;td&gt;Secure credentials in pipeline&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Deployment Verification&lt;/td&gt;
&lt;td&gt;Admission Controller&lt;/td&gt;
&lt;td&gt;Block unsigned images&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Monitoring&lt;/td&gt;
&lt;td&gt;SecurityHub&lt;/td&gt;
&lt;td&gt;Aggregate security findings&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Audit&lt;/td&gt;
&lt;td&gt;CloudTrail&lt;/td&gt;
&lt;td&gt;Track all security events&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;When all these pieces work together, you have a comprehensive DevSecOps pipeline that addresses security at every stage — exactly what NIST recommends.&lt;/p&gt;

&lt;h2&gt;
  
  
  Common Mistakes to Avoid
&lt;/h2&gt;

&lt;p&gt;Based on my experience implementing DevSecOps pipelines, here are some mistakes I've seen teams make with container signing:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 1: Signing but not verifying&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Some teams implement signing but forget to enforce verification. This gives you a false sense of security. Always implement admission controllers or lifecycle hooks to verify signatures before deployment.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 2: Using the same signing profile for all environments&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;If your dev and production images use the same signing profile, a dev image could theoretically be deployed to production. Use separate profiles for different environments.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 3: Not integrating with your security dashboard&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Container signing generates valuable security data. Make sure it flows into SecurityHub so your security team has visibility into your signing operations.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 4: Skipping the audit trail&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;CloudTrail logs are essential for compliance. Don't disable them thinking it will save costs — the compliance risk is not worth it.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Business Case for Container Signing
&lt;/h2&gt;

&lt;p&gt;If you need to convince your team or management to implement container signing, here are the key points:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Compliance&lt;/strong&gt;: NIST, SOC2, PCI-DSS, and ISO 27001 all have requirements around software integrity. Container signing helps meet these requirements.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Risk Reduction&lt;/strong&gt;: Supply chain attacks like SolarWinds showed us what happens when software integrity is compromised. Container signing is a preventive control.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Operational Simplicity&lt;/strong&gt;: With AWS Managed Signing, the implementation cost is minimal. It's essentially a few clicks to set up.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Audit Readiness&lt;/strong&gt;: When auditors ask "how do you verify the integrity of your deployments?", you'll have a clear answer with evidence in CloudTrail.&lt;/p&gt;

&lt;h2&gt;
  
  
  Conclusion
&lt;/h2&gt;

&lt;p&gt;Container signing is a critical component of a mature DevSecOps pipeline. It bridges the gap between your security scanning stages and your deployment stages, ensuring that only verified, approved images make it to production.&lt;/p&gt;

&lt;p&gt;What I appreciate most about AWS Managed Signing is that it removes the barriers to adoption. In the past, teams had legitimate reasons to skip container signing — it was complex and time-consuming. Now, with just a few clicks, you can add this security layer to your CI/CD pipeline without modifying your build scripts.&lt;/p&gt;

&lt;p&gt;If you've been following my DevSecOps series, you'll see how container signing fits into the bigger picture. It's a practical implementation of the NIST guidelines I discussed previously, and it strengthens the "shift left" approach I outlined in my DevSecOps evolution article.&lt;/p&gt;

&lt;p&gt;My recommendation? Start small. Enable managed signing for one repository, verify it works, and then expand to your entire pipeline. Security is a journey, not a destination.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below. So, I know about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>cicd</category>
      <category>cybersecurity</category>
      <category>aws</category>
      <category>devsecops</category>
    </item>
    <item>
      <title>My Perspective on SBOM: The Glue for DevSecOps</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Wed, 31 Dec 2025 09:37:35 +0000</pubDate>
      <link>https://forem.com/iilness2/my-perspective-on-sbom-the-glue-for-devsecops-3g7k</link>
      <guid>https://forem.com/iilness2/my-perspective-on-sbom-the-glue-for-devsecops-3g7k</guid>
      <description>&lt;p&gt;If you've been following my recent articles, I've been writing about different pieces of DevSecOps on AWS — from &lt;a href="https://dev.to/iilness2/my-perspective-on-amazon-inspectors-2025-updates-for-devsecops-218m"&gt;Amazon Inspector&lt;/a&gt; for scanning, &lt;a href="https://dev.to/iilness2/implementing-container-signing-in-your-cicd-pipeline-a-devsecops-approach-with-aws-2k32"&gt;Container Signing&lt;/a&gt; for integrity, to &lt;a href="https://dev.to/iilness2/my-perspective-on-aws-security-hub-for-devsecops-40e8"&gt;Security Hub&lt;/a&gt; for centralized visibility.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;So why am I talking about SBOM now?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Because SBOM is what ties all of these together.&lt;/p&gt;

&lt;h2&gt;
  
  
  What is SBOM?
&lt;/h2&gt;

&lt;p&gt;SBOM — Software Bill of Materials — is basically a list of all third-party libraries your application uses. That's it. Nothing fancy.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Why does this matter?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Think about when Log4j happened. Teams everywhere were scrambling to answer one question: "Do we use this library?" For those who had an SBOM, the answer was quick. For those who didn't, it took days or even weeks to figure out.&lt;/p&gt;

&lt;p&gt;Beyond incidents, SBOM also helps during audits. When someone asks "what's inside your software?", you have the documentation ready.&lt;/p&gt;

&lt;h2&gt;
  
  
  How SBOM Ties Everything Together
&lt;/h2&gt;

&lt;p&gt;SBOM has known formats — CycloneDX and SPDX are the common ones. With these standard formats, you can integrate with other security tools that support it.&lt;/p&gt;

&lt;p&gt;This is where the connection happens:&lt;/p&gt;

&lt;p&gt;Amazon Inspector can generate SBOM in these formats. So after scanning your containers and code, you also get a list of what's inside. Container Signing verifies that the image hasn't been tampered with. Security Hub gives you visibility across all findings.&lt;/p&gt;

&lt;p&gt;Put it together: you know what's inside your software (SBOM), it's been scanned for vulnerabilities (Inspector), it's signed and verified (Container Signing), and you can monitor everything from one place (Security Hub).&lt;/p&gt;

&lt;p&gt;SBOM is the glue that makes all of this make sense.&lt;/p&gt;

&lt;h2&gt;
  
  
  Closing
&lt;/h2&gt;

&lt;p&gt;For me, SBOM completes the picture. It's not a tool you interact with daily, but it's the foundation that connects your scanning, signing, and monitoring together.&lt;/p&gt;

&lt;p&gt;If you're building a DevSecOps practice, understanding SBOM is part of knowing your stuff.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>devsecops</category>
      <category>devops</category>
      <category>softwaredevelopment</category>
    </item>
    <item>
      <title>My Perspective on AWS Security Hub for DevSecOps</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Wed, 31 Dec 2025 03:31:00 +0000</pubDate>
      <link>https://forem.com/iilness2/my-perspective-on-aws-security-hub-for-devsecops-40e8</link>
      <guid>https://forem.com/iilness2/my-perspective-on-aws-security-hub-for-devsecops-40e8</guid>
      <description>&lt;p&gt;In my previous article, I shared my perspective on &lt;a href="https://dev.to/iilness2/my-perspective-on-amazon-inspectors-2025-updates-for-devsecops-218m"&gt;Amazon Inspector's 2025 updates&lt;/a&gt; and how it now covers most areas in DevSecOps. At the end of that article, I mentioned Security Hub as the place where all these findings come together.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;So why am I talking about Security Hub?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Because from my perspective, it's the central piece that ties everything together.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Problem &amp;amp; Why Security Hub Helps
&lt;/h2&gt;

&lt;p&gt;In today's world, we need to comply with various standards — whether it's &lt;a href="https://dev.to/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m"&gt;NIST guidelines&lt;/a&gt; that I discussed before, CIS Benchmarks, or PCI-DSS for those handling payment data. With all these compliance requirements, a lot of security models and stages have been introduced lately.&lt;/p&gt;

&lt;p&gt;What does this mean for us? More dashboards to monitor.&lt;/p&gt;

&lt;p&gt;Especially for people who work on operations, this becomes overwhelming. You have findings from Inspector, alerts from GuardDuty, issues from IAM Access Analyzer, and the list goes on. Jumping between consoles just to get a complete picture of your security posture is not efficient.&lt;/p&gt;

&lt;p&gt;This is where Security Hub helps.&lt;/p&gt;

&lt;p&gt;Security Hub acts as a single place where all your security findings are aggregated. Instead of checking multiple dashboards, you get one consolidated view. From my experience, this saves a lot of time — especially when you need to report the overall security status to stakeholders or during audits.&lt;/p&gt;

&lt;p&gt;What I find useful is the integration with other AWS security tools. Inspector findings for vulnerabilities, GuardDuty for threat detection, Macie for data security — all flow into Security Hub automatically. If you're managing multiple AWS accounts in an organization, the cross-account visibility is also helpful. You can see the security posture across all accounts from one place.&lt;/p&gt;

&lt;p&gt;For compliance, Security Hub also provides automated checks against standards like CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. This helps when you need to demonstrate compliance during audits.&lt;/p&gt;

&lt;h2&gt;
  
  
  What It Doesn't Solve
&lt;/h2&gt;

&lt;p&gt;Being honest here — Security Hub is great for aggregating findings, but it doesn't cover everything.&lt;/p&gt;

&lt;p&gt;For areas like DAST (Dynamic Application Security Testing), you still need to look elsewhere. As I mentioned in my &lt;a href="https://dev.to/iilness2/practical-way-for-security-assestment-in-aws-with-prowler-4i85"&gt;Prowler article&lt;/a&gt;, there are other tools that complement what AWS provides natively.&lt;/p&gt;

&lt;p&gt;Security Hub is the central piece, but it's not the only piece.&lt;/p&gt;

&lt;h2&gt;
  
  
  Closing
&lt;/h2&gt;

&lt;p&gt;From my perspective as someone working in DevSecOps, Security Hub brings value by reducing the complexity of monitoring multiple security tools. In a world where compliance requirements keep growing, having one place to see everything matters.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>devops</category>
      <category>cybersecurity</category>
      <category>productivity</category>
    </item>
    <item>
      <title>My Perspective on Amazon Inspector's 2025 Updates for DevSecOps</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Tue, 30 Dec 2025 09:26:43 +0000</pubDate>
      <link>https://forem.com/iilness2/my-perspective-on-amazon-inspectors-2025-updates-for-devsecops-218m</link>
      <guid>https://forem.com/iilness2/my-perspective-on-amazon-inspectors-2025-updates-for-devsecops-218m</guid>
      <description>&lt;h2&gt;
  
  
  Introduction
&lt;/h2&gt;

&lt;p&gt;Back in early 2024, I wrote about &lt;a href="https://dev.to/iilness2/latest-improvements-in-amazon-inspector-from-reinvent-2023-from-my-perspective-291n"&gt;My Perspective on the Latest Improvements in Amazon Inspector from re:Invent 2023&lt;/a&gt;. At that time, AWS focused more on Lambda code scanning and agentless EC2 scanning.&lt;/p&gt;

&lt;p&gt;Fast forward to 2025, and Amazon Inspector has evolved significantly. As a DevSecOps practitioner, I put my eyes on all the new features that they bring.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;So what's changed in the past two years?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;In this article, I want to share what's new in Amazon Inspector for 2025 and how these updates benefit us as DevSecOps Engineers.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;em&gt;What's New in Amazon Inspector 2025?&lt;/em&gt;
&lt;/h2&gt;

&lt;p&gt;Let me walk you through the key updates since my last article.&lt;/p&gt;

&lt;h3&gt;
  
  
  Enhanced Container Scanning Engine (February 2025)
&lt;/h3&gt;

&lt;p&gt;AWS upgraded the engine that powers container image scanning for Amazon ECR. This update provides better dependency detection, more comprehensive vulnerability findings, and automatic re-evaluation of existing resources.&lt;/p&gt;

&lt;p&gt;In my 2023 article, I talked about ECR scanning capabilities. The 2025 engine upgrade makes those scans more accurate and thorough. The best part? This upgrade happened automatically. You don't need to do anything.&lt;/p&gt;

&lt;h3&gt;
  
  
  Code Security (GA - June 2025)
&lt;/h3&gt;

&lt;p&gt;This is the biggest update in my opinion. In my 2023 article, I talked about how Inspector could scan Lambda functions and container images. Now, it can scan your &lt;strong&gt;source code&lt;/strong&gt; directly — before you even build anything.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Why is this important?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;From my experience, finding a vulnerability in code costs 10x less than finding it in production. The earlier you catch the issue, the cheaper it is to fix.&lt;/p&gt;

&lt;p&gt;Code Security includes SAST for scanning your source code, SCA for scanning third-party dependencies, and IaC scanning for your Terraform and CloudFormation templates. It also has native GitHub and GitLab integration — findings appear directly in your Pull Requests.&lt;/p&gt;

&lt;h3&gt;
  
  
  Organization-wide Management (November 2025)
&lt;/h3&gt;

&lt;p&gt;If you've ever tried to enable Amazon Inspector across multiple AWS accounts, you know the pain. In my previous article, I mentioned how Inspector integrates with AWS Organizations. But back then, you still had to configure each account.&lt;/p&gt;

&lt;p&gt;Not anymore. AWS introduced Organization-wide Management using AWS Organizations policies. Now, one policy covers all accounts, new accounts get auto-enrollment, and you have a consistent baseline across your organization.&lt;/p&gt;

&lt;p&gt;As a DevSecOps Engineer, this saves me hours of setup and ensures no account is left unprotected.&lt;/p&gt;

&lt;h3&gt;
  
  
  Security Hub Integration (re:Invent 2025 - December)
&lt;/h3&gt;

&lt;p&gt;Amazon Inspector findings now integrate seamlessly with AWS Security Hub. Security Hub correlates signals from Inspector, GuardDuty, and Macie to provide near real-time risk analytics.&lt;/p&gt;

&lt;p&gt;I'll cover Security Hub in detail in my next article — it deserves its own deep dive.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;em&gt;What Are the Benefits as DevSecOps Engineer?&lt;/em&gt;
&lt;/h2&gt;

&lt;p&gt;With this improvement, as a DevSecOps Engineer, I think it's covering the main areas in DevSecOps now.&lt;/p&gt;

&lt;p&gt;As DevSecOps, we also focus on security. And I always felt the gap where when we're doing implementation in AWS, we always need to look at third-party tools for covering SAST, SCA, even parts like IaC scanning and container scanning. We had to set up separate tools like Snyk, Checkov, or Trivy, and then figure out how to integrate them with our AWS environment.&lt;/p&gt;

&lt;p&gt;But with this improvement, Inspector now covers all these parts. SAST for scanning source code, SCA for scanning dependencies, IaC scanning for Terraform and CloudFormation, and container scanning for ECR images.&lt;/p&gt;

&lt;p&gt;The only thing missing is DAST (Dynamic Application Security Testing) — we still need to look elsewhere for that. For DAST, I find Prowler is an interesting tool which you can read in my article &lt;a href="https://dev.to/iilness2/practical-way-for-security-assestment-in-aws-with-prowler-4i85"&gt;Practical Way for Security Assessment in AWS with Prowler&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;So now we can have a complete DevSecOps chain that covers all my application supply chain — from code to runtime.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;What about if you're already using AWS?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;This is where Inspector really shines. If you're already on AWS, the integration is seamless. ECR automatically scans on image push. CodePipeline and CodeBuild have native integration. EventBridge can trigger automated workflows. Organizations let you manage multiple accounts with a single policy. And CloudTrail provides audit logging for compliance.&lt;/p&gt;

&lt;p&gt;You don't need to set up separate tools and figure out how to connect them. It's already integrated with your AWS environment.&lt;/p&gt;

&lt;p&gt;And speaking of compliance — in my article about &lt;a href="https://dev.to/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m"&gt;NIST Guidelines&lt;/a&gt;, I discussed how organizations need to follow security frameworks. This is the best part — Inspector also directly supports generating SBOM in CycloneDX and SPDX formats. This part, we can combine with CloudTrail for audit trails.&lt;/p&gt;

&lt;p&gt;With CycloneDX and SPDX formats, you can also integrate with other tools that support the format as well, like GitLab. So you're not locked into AWS — you have flexibility to use SBOM data across your toolchain.&lt;/p&gt;

&lt;h2&gt;
  
  
  Conclusion
&lt;/h2&gt;

&lt;p&gt;Since I wrote my 2023 article, a lot has improved in Amazon Inspector. The 2025 updates — especially Code Security and Organization-wide Management — have transformed Inspector from a vulnerability scanner into a comprehensive DevSecOps platform.&lt;/p&gt;

&lt;p&gt;From my perspective as a DevSecOps Engineer, Inspector now covers most of what I need. And if you're already using AWS, the integration is seamless.&lt;/p&gt;

&lt;p&gt;In my next article, I'll dive into AWS Security Hub and how it brings all your security findings together into a single view. Stay tuned!&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below. So, I know about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>devsecops</category>
      <category>cicd</category>
      <category>security</category>
    </item>
    <item>
      <title>Implementing Container Signing in Your CI/CD Pipeline: A DevSecOps Approach with AWS</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Mon, 29 Dec 2025 16:51:44 +0000</pubDate>
      <link>https://forem.com/iilness2/implementing-container-signing-in-your-cicd-pipeline-a-devsecops-approach-with-aws-2k32</link>
      <guid>https://forem.com/iilness2/implementing-container-signing-in-your-cicd-pipeline-a-devsecops-approach-with-aws-2k32</guid>
      <description>&lt;h2&gt;
  
  
  Introduction
&lt;/h2&gt;

&lt;p&gt;This article is part of my ongoing series about DevOps and DevSecOps practices. If you've been following along, you may have read my previous articles on &lt;a href="https://dev.to/iilness2/perspectives-on-the-evolution-of-devsecops-engineering-based-on-from-my-experiences-21me"&gt;the evolution of DevSecOps&lt;/a&gt; and &lt;a href="https://dev.to/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m"&gt;how NIST guidelines enhance software security&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;In my NIST article, I discussed how security should be embedded into every stage of the Software Development Life Cycle (SDLC). I also mentioned tools like AWS CodeBuild, CodePipeline, and SecurityHub as part of a DevSecOps pipeline. Today, I want to add another critical piece to that puzzle: &lt;strong&gt;Container Signing&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;As someone who has been working with CI/CD pipelines for several years, I've noticed that container signing is often the "forgotten step" in many pipelines. Teams invest heavily in SAST, DAST, and SCA scanning, but skip image signing because it used to be complex to implement. With AWS's new Managed Signing feature released in November 2025, that excuse no longer holds.&lt;/p&gt;

&lt;p&gt;Let me walk you through why container signing matters in DevSecOps and how to integrate it into your CI/CD pipeline.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why Container Signing Matters in DevSecOps
&lt;/h2&gt;

&lt;p&gt;In my previous article about DevSecOps evolution, I explained the concept of "shifting security left" — integrating security practices early in the development process rather than treating it as an afterthought. Container signing is a perfect example of this principle in action.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;What Problem Does It Solve?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Think about your current CI/CD pipeline. You probably have something like this:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5p7dliyne0rkuzsahwht.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5p7dliyne0rkuzsahwht.png" alt="CICD Old Way" width="800" height="173"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;But here's a question I often ask teams: &lt;strong&gt;How do you know the image you're deploying is the same image that passed your security scans?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Between your build stage and deployment stage, several things could go wrong:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Someone could push a modified image to your registry&lt;/li&gt;
&lt;li&gt;A compromised CI/CD runner could inject malicious code&lt;/li&gt;
&lt;li&gt;An attacker could perform a man-in-the-middle attack&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Without container signing, you're essentially trusting that nothing bad happened between your build and deploy stages. In DevSecOps, we call this a &lt;strong&gt;supply chain risk&lt;/strong&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  The DevSecOps Pipeline: Where Container Signing Fits
&lt;/h2&gt;

&lt;p&gt;Let me show you where container signing fits in a proper DevSecOps pipeline. This builds on the pipeline I discussed in my NIST article:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8ls12x4q7ku28r6ii27h.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8ls12x4q7ku28r6ii27h.png" alt="DevSecOps Pipeline" width="800" height="264"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Notice the &lt;strong&gt;SIGN&lt;/strong&gt; and &lt;strong&gt;VERIFY&lt;/strong&gt; stages. These are what most pipelines are missing. Let me explain each:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;SIGN Stage&lt;/strong&gt;: After your image passes all security scans (SAST, DAST, SCA, vulnerability scanning), it gets signed. This signature proves that the image has been vetted and approved for deployment.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;VERIFY Stage&lt;/strong&gt;: Before deployment, an admission controller checks the signature. If the signature is invalid or missing, the deployment is blocked. No exceptions.&lt;/p&gt;

&lt;p&gt;This approach aligns with what NIST calls "verifying the integrity of software components" — one of the key recommendations I highlighted in my previous article.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Old Way vs The New Way
&lt;/h2&gt;

&lt;p&gt;Before we dive into implementation, let me share why container signing was often skipped in CI/CD pipelines.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;The Old Way (Before November 2025)&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;To sign containers, you had to:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Install Notation CLI on your build server&lt;/li&gt;
&lt;li&gt;Install AWS Signer plugin&lt;/li&gt;
&lt;li&gt;Configure authentication between Notation and ECR&lt;/li&gt;
&lt;li&gt;Manage signing keys and certificates&lt;/li&gt;
&lt;li&gt;Add multiple commands to your buildspec.yml&lt;/li&gt;
&lt;li&gt;Handle token refresh (tokens expire after 12 hours)&lt;/li&gt;
&lt;li&gt;Troubleshoot cryptographic errors&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;For teams already juggling complex pipelines, this was too much overhead. I've seen many teams evaluate container signing and decide "we'll implement it later" — and later never comes.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;The New Way (AWS Managed Signing)&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;With AWS Managed Signing, the process becomes:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Create a signing profile (one-time setup)&lt;/li&gt;
&lt;li&gt;Create a signing rule in ECR (one-time setup)&lt;/li&gt;
&lt;li&gt;Push your image — it's automatically signed&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;No changes to your buildspec.yml. No additional tools to install. No keys to manage.&lt;/p&gt;

&lt;p&gt;This is the kind of simplification that makes DevSecOps adoption realistic for teams of all sizes.&lt;/p&gt;

&lt;h2&gt;
  
  
  Setting Up Container Signing in Your CI/CD Pipeline
&lt;/h2&gt;

&lt;p&gt;Let me walk you through how to integrate container signing into your existing AWS CI/CD pipeline.&lt;/p&gt;

&lt;h3&gt;
  
  
  Prerequisites
&lt;/h3&gt;

&lt;p&gt;Before we start, you should have:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;An existing CI/CD pipeline using CodePipeline and CodeBuild&lt;/li&gt;
&lt;li&gt;Container images stored in Amazon ECR&lt;/li&gt;
&lt;li&gt;Basic understanding of IAM permissions&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  Step 1: Create an AWS Signer Signing Profile
&lt;/h3&gt;

&lt;p&gt;The signing profile defines how your images will be signed. Think of it as a template for your signatures.&lt;/p&gt;

&lt;p&gt;Go to AWS Signer in the console:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Click &lt;strong&gt;Create signing profile&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Select &lt;strong&gt;Notation for container registries&lt;/strong&gt; as the platform&lt;/li&gt;
&lt;li&gt;Enter a profile name (e.g., &lt;code&gt;production-container-signing&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;Set the signature validity period (I recommend starting with the default 135 months)&lt;/li&gt;
&lt;li&gt;Click &lt;strong&gt;Create&lt;/strong&gt;
&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;em&gt;Pro Tip&lt;/em&gt;: Create separate signing profiles for different environments. I typically use:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;dev-container-signing&lt;/code&gt; for development&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;staging-container-signing&lt;/code&gt; for staging&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;production-container-signing&lt;/code&gt; for production&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This allows you to track which environment an image was approved for.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 2: Configure ECR Managed Signing
&lt;/h3&gt;

&lt;p&gt;Now, tell ECR to automatically sign images when they're pushed.&lt;/p&gt;

&lt;p&gt;In the ECR console:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Go to &lt;strong&gt;Private registry&lt;/strong&gt; → &lt;strong&gt;Features &amp;amp; settings&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Under &lt;strong&gt;Managed Signing&lt;/strong&gt;, click &lt;strong&gt;Configure&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Click &lt;strong&gt;Create rule&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Select your signing profile from Step 1&lt;/li&gt;
&lt;li&gt;Add a repository filter (e.g., &lt;code&gt;prod-*&lt;/code&gt; to sign all production repositories)&lt;/li&gt;
&lt;li&gt;Click &lt;strong&gt;Create&lt;/strong&gt;
&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;That's it for the signing setup. Your images will now be automatically signed when pushed to matching repositories.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 3: Update Your CI/CD Pipeline
&lt;/h3&gt;

&lt;p&gt;Here's the beauty of AWS Managed Signing: &lt;strong&gt;you don't need to change your buildspec.yml&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;Your existing buildspec probably looks something like this:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight yaml"&gt;&lt;code&gt;&lt;span class="na"&gt;version&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="m"&gt;0.2&lt;/span&gt;

&lt;span class="na"&gt;phases&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
  &lt;span class="na"&gt;pre_build&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="na"&gt;commands&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;echo Logging in to Amazon ECR...&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $ECR_REGISTRY&lt;/span&gt;

  &lt;span class="na"&gt;build&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="na"&gt;commands&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;echo Building Docker image...&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;docker build -t $IMAGE_NAME:$IMAGE_TAG .&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;docker tag $IMAGE_NAME:$IMAGE_TAG $ECR_REGISTRY/$IMAGE_NAME:$IMAGE_TAG&lt;/span&gt;

  &lt;span class="na"&gt;post_build&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="na"&gt;commands&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;echo Pushing to ECR...&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;docker push $ECR_REGISTRY/$IMAGE_NAME:$IMAGE_TAG&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;With managed signing enabled, the signing happens automatically during &lt;code&gt;docker push&lt;/code&gt;. No additional commands needed.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 4: Implement Signature Verification
&lt;/h3&gt;

&lt;p&gt;Signing is only half of the equation. To complete the security chain, you need to verify signatures before deployment.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;For Amazon EKS&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;If you're using EKS, you can implement verification using admission controllers like Kyverno or Ratify. These controllers intercept pod creation requests and verify the container image signature before allowing deployment.&lt;/p&gt;

&lt;p&gt;Here's a simple example of what a Kyverno policy might look like:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight yaml"&gt;&lt;code&gt;&lt;span class="na"&gt;apiVersion&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;kyverno.io/v1&lt;/span&gt;
&lt;span class="na"&gt;kind&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;ClusterPolicy&lt;/span&gt;
&lt;span class="na"&gt;metadata&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
  &lt;span class="na"&gt;name&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;verify-container-signatures&lt;/span&gt;
&lt;span class="na"&gt;spec&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
  &lt;span class="na"&gt;validationFailureAction&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;Enforce&lt;/span&gt;
  &lt;span class="na"&gt;background&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="kc"&gt;false&lt;/span&gt;
  &lt;span class="na"&gt;rules&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
    &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="na"&gt;name&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="s"&gt;verify-signature&lt;/span&gt;
      &lt;span class="na"&gt;match&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
        &lt;span class="na"&gt;any&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
        &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="na"&gt;resources&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
            &lt;span class="na"&gt;kinds&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
              &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s"&gt;Pod&lt;/span&gt;
      &lt;span class="na"&gt;verifyImages&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
      &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="na"&gt;imageReferences&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt;
        &lt;span class="pi"&gt;-&lt;/span&gt; &lt;span class="s2"&gt;"&lt;/span&gt;&lt;span class="s"&gt;*.dkr.ecr.*.amazonaws.com/*"&lt;/span&gt;
        &lt;span class="na"&gt;required&lt;/span&gt;&lt;span class="pi"&gt;:&lt;/span&gt; &lt;span class="kc"&gt;true&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;This policy enforces that all images from ECR must have a valid signature. If an unsigned image is deployed, the pod creation will be rejected.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;For Amazon ECS&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;For ECS, you can use service lifecycle hooks with Lambda to verify signatures before deployment. The Lambda function runs during the PRE_SCALE_UP phase, checking the signature before any containers are started.&lt;/p&gt;

&lt;h3&gt;
  
  
  Step 5: Enable Audit Logging
&lt;/h3&gt;

&lt;p&gt;As I mentioned in my NIST article, traceability is crucial for compliance. AWS CloudTrail automatically logs all signing operations, giving you a complete audit trail.&lt;/p&gt;

&lt;p&gt;Make sure CloudTrail is enabled in your account, and you'll have records of:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Who pushed the image&lt;/li&gt;
&lt;li&gt;When it was signed&lt;/li&gt;
&lt;li&gt;Which signing profile was used&lt;/li&gt;
&lt;li&gt;The signature details&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This information is invaluable for security audits and incident response.&lt;/p&gt;

&lt;h2&gt;
  
  
  Connecting to Your DevSecOps Toolchain
&lt;/h2&gt;

&lt;p&gt;Container signing doesn't exist in isolation. It's part of a broader DevSecOps strategy. Here's how it connects to other AWS security services I've discussed in my previous articles:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Stage&lt;/th&gt;
&lt;th&gt;AWS Service&lt;/th&gt;
&lt;th&gt;Purpose&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Code Quality&lt;/td&gt;
&lt;td&gt;CodeGuru&lt;/td&gt;
&lt;td&gt;Identify code issues early&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Vulnerability Scan&lt;/td&gt;
&lt;td&gt;Amazon Inspector&lt;/td&gt;
&lt;td&gt;Find CVEs in your images&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;Image Signing&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;AWS Signer + ECR&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;Prove image authenticity&lt;/strong&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Secret Management&lt;/td&gt;
&lt;td&gt;Secrets Manager&lt;/td&gt;
&lt;td&gt;Secure credentials in pipeline&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Deployment Verification&lt;/td&gt;
&lt;td&gt;Admission Controller&lt;/td&gt;
&lt;td&gt;Block unsigned images&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Monitoring&lt;/td&gt;
&lt;td&gt;SecurityHub&lt;/td&gt;
&lt;td&gt;Aggregate security findings&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Audit&lt;/td&gt;
&lt;td&gt;CloudTrail&lt;/td&gt;
&lt;td&gt;Track all security events&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;When all these pieces work together, you have a comprehensive DevSecOps pipeline that addresses security at every stage — exactly what NIST recommends.&lt;/p&gt;

&lt;h2&gt;
  
  
  Common Mistakes to Avoid
&lt;/h2&gt;

&lt;p&gt;Based on my experience implementing DevSecOps pipelines, here are some mistakes I've seen teams make with container signing:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 1: Signing but not verifying&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Some teams implement signing but forget to enforce verification. This gives you a false sense of security. Always implement admission controllers or lifecycle hooks to verify signatures before deployment.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 2: Using the same signing profile for all environments&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;If your dev and production images use the same signing profile, a dev image could theoretically be deployed to production. Use separate profiles for different environments.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 3: Not integrating with your security dashboard&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Container signing generates valuable security data. Make sure it flows into SecurityHub so your security team has visibility into your signing operations.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mistake 4: Skipping the audit trail&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;CloudTrail logs are essential for compliance. Don't disable them thinking it will save costs — the compliance risk is not worth it.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Business Case for Container Signing
&lt;/h2&gt;

&lt;p&gt;If you need to convince your team or management to implement container signing, here are the key points:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Compliance&lt;/strong&gt;: NIST, SOC2, PCI-DSS, and ISO 27001 all have requirements around software integrity. Container signing helps meet these requirements.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Risk Reduction&lt;/strong&gt;: Supply chain attacks like SolarWinds showed us what happens when software integrity is compromised. Container signing is a preventive control.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Operational Simplicity&lt;/strong&gt;: With AWS Managed Signing, the implementation cost is minimal. It's essentially a few clicks to set up.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Audit Readiness&lt;/strong&gt;: When auditors ask "how do you verify the integrity of your deployments?", you'll have a clear answer with evidence in CloudTrail.&lt;/p&gt;

&lt;h2&gt;
  
  
  Conclusion
&lt;/h2&gt;

&lt;p&gt;Container signing is a critical component of a mature DevSecOps pipeline. It bridges the gap between your security scanning stages and your deployment stages, ensuring that only verified, approved images make it to production.&lt;/p&gt;

&lt;p&gt;What I appreciate most about AWS Managed Signing is that it removes the barriers to adoption. In the past, teams had legitimate reasons to skip container signing — it was complex and time-consuming. Now, with just a few clicks, you can add this security layer to your CI/CD pipeline without modifying your build scripts.&lt;/p&gt;

&lt;p&gt;If you've been following my DevSecOps series, you'll see how container signing fits into the bigger picture. It's a practical implementation of the NIST guidelines I discussed previously, and it strengthens the "shift left" approach I outlined in my DevSecOps evolution article.&lt;/p&gt;

&lt;p&gt;My recommendation? Start small. Enable managed signing for one repository, verify it works, and then expand to your entire pipeline. Security is a journey, not a destination.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below. So, I know about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>cicd</category>
      <category>cybersecurity</category>
      <category>aws</category>
      <category>devsecops</category>
    </item>
    <item>
      <title>The Future of DevSecOps: Enhancing Your Software Security Development with NIST Guidelines</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Sat, 21 Sep 2024 06:00:20 +0000</pubDate>
      <link>https://forem.com/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m</link>
      <guid>https://forem.com/iilness2/the-future-of-devsecops-how-nist-guidelines-enhance-software-security-220m</guid>
      <description>&lt;h2&gt;
  
  
  Introduction
&lt;/h2&gt;

&lt;p&gt;In the fast-paced world of software development, staying ahead of security threats is not just a priority—it's a necessity. As the software development and deployment landscape evolves, so must our security strategies. In recent years, the National Institute of Standards and Technology (NIST) has published guidance emphasizing the importance of embedding robust security measures into every stage of the development lifecycle. For DevSecOps specialists, applying these principles is essential to maintaining a secure and compliant environment.&lt;/p&gt;

&lt;h2&gt;
  
  
  Key Areas of Security in DevSecOps
&lt;/h2&gt;

&lt;p&gt;Becoming a cybersecurity expert requires deep knowledge across several critical areas. As emphasized in this &lt;a href="https://dev.to/thenjdevopsguy/what-you-actually-need-to-know-for-a-cybersecurity-job-3nnk"&gt;article&lt;/a&gt;, professionals should focus on mastering these core security domains:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;Infrastructure&lt;/strong&gt; – Ensuring that servers, data centers, and other physical assets are secure.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Networks&lt;/strong&gt; – Safeguarding communication channels to prevent unauthorized access or data breaches.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Software&lt;/strong&gt; – Implementing secure coding practices to prevent vulnerabilities within applications.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Cloud&lt;/strong&gt; – Securing cloud environments to protect data integrity and confidentiality.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;For DevSecOps specialists, the emphasis is often on software security. This involves ensuring that every component of the Software Development Life Cycle (SDLC) strengthens the software and mitigates potential threats.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Role of NIST in DevSecOps and Why It Matters
&lt;/h2&gt;

&lt;p&gt;Since November 2022, the National Institute of Standards and Technology (NIST) has provided crucial guidance to reduce risks in the software supply chain through the application of DevSecOps practices. NIST’s framework enhances security and ensures compliance within Continuous Integration/Continuous Deployment (CI/CD) environments. By offering a comprehensive framework, NIST outlines essential practices for aligning software development, security, supply chains, and deployment processes with regulatory standards and industry best practices. For more details on their approach, you can access the full publication &lt;a href="https://csrc.nist.gov/pubs/pd/2022/11/09/implementing-a-riskbased-approach-to-devsecops/final" rel="noopener noreferrer"&gt;here&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;As a DevOps professional, I have witnessed firsthand the rapid evolution of tools and practices. One of the most impactful developments has been NIST’s contributions in setting a standard for the DevSecOps community. Their guidelines provide a solid foundation for integrating security into every phase of the SDLC, addressing vulnerabilities proactively rather than reactively.&lt;/p&gt;

&lt;p&gt;With these NIST guidelines, organizations are better equipped to adopt stronger security practices moving forward. Although companies may have specific security needs, NIST’s unified approach brings everyone together toward the common goal of continuous improvement. By following these standards, organizations can align on key security issues, driving more effective practices and reducing risks throughout the software supply chain.&lt;/p&gt;

&lt;h2&gt;
  
  
  Practical Application for the approach in DevSecOps
&lt;/h2&gt;

&lt;p&gt;While NIST provides a valuable framework, it's important to note that it serves more as a guideline rather than a ready-to-use platform. Implementing these recommendations within your specific processes still requires effort. In practice, to integrate an effective DevSecOps framework into the Software Development Lifecycle (SDLC), we can leverage existing tools and platforms from companies that have already developed mature solutions.&lt;/p&gt;

&lt;p&gt;One platform I’ve personally used and highly recommend is GitLab. GitLab’s DevSecOps offering is comprehensive and user-friendly. You can explore their platform &lt;a href="https://about.gitlab.com/free-trial/devsecops/" rel="noopener noreferrer"&gt;here&lt;/a&gt;. It includes useful features such as detailed vulnerability reports, which help monitor and enhance the security of your applications.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F9yg0q0jlq6n8zos8nt9e.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F9yg0q0jlq6n8zos8nt9e.png" alt="Gitlab" width="" height=""&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Another promising option to consider is the AWS platform, utilizing a combination of key services such as AWS CodeBuild, CodeCommit, CodePipeline, and SecurityHub. These services integrate seamlessly with open-source security tools to create a comprehensive CI/CD pipeline. You can explore a detailed implementation guide &lt;a href="https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/" rel="noopener noreferrer"&gt;here&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Additionally, AWS continues to enhance its offerings with services like Amazon Inspector, which has received significant updates that I previously reviewed &lt;a href="https://dev.to/iilness2/latest-improvements-in-amazon-inspector-from-reinvent-2023-from-my-perspective-291n"&gt;here&lt;/a&gt;. By incorporating these tools into your security strategy, you can strengthen your software development lifecycle (SDLC) and ensure robust security measures at every stage.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F7b8ncwljgbpgyx62dj07.jpeg" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F7b8ncwljgbpgyx62dj07.jpeg" alt="AWS" width="" height=""&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Lastly, ArmourZero, a newer entrant in the DevSecOps space. ArmourZero provides a complete set of tools designed to seamlessly integrate into your SDLC. Learn more about their platform &lt;a href="https://armourzero.com/go/HIxUGkQutSQjwxsOIiXwDopdyOYjkFgiUMcEOwzUtMxQvsWNHzDvzNwvQoRW" rel="noopener noreferrer"&gt;here&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F93k7fkdkun93sfv2dhtf.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F93k7fkdkun93sfv2dhtf.png" alt="ArmourZero" width="" height=""&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  Conclusion
&lt;/h2&gt;

&lt;p&gt;DevSecOps is integral to securing modern software development pipelines, and its importance will only grow as security threats continue to evolve. By embedding security directly into CI/CD processes, DevSecOps ensures that vulnerabilities are identified and addressed early, minimizing risks throughout the software supply chain.&lt;/p&gt;

&lt;p&gt;NIST’s guidelines provide a structured approach to DevSecOps, offering a unified framework that organizations can rely on to strengthen security practices. These guidelines help to ensure that security is not just an afterthought but a fundamental part of every phase of the SDLC.&lt;/p&gt;

&lt;p&gt;Looking ahead, the impact of DevSecOps combined with NIST’s evolving standards will become even more significant. As cyber threats become more sophisticated, integrating security practices into the core of development will be essential for building resilient, secure systems. By adopting NIST’s guidelines, organizations can enhance their DevSecOps strategies, ensuring that they are well-equipped to meet future security challenges.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>cicd</category>
      <category>cybersecurity</category>
      <category>devsecops</category>
      <category>productivity</category>
    </item>
    <item>
      <title>Practical Way to Use AWS Glue with Postgresql</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Thu, 06 Jun 2024 09:12:58 +0000</pubDate>
      <link>https://forem.com/iilness2/practical-way-to-use-aws-glue-with-postgresql-1887</link>
      <guid>https://forem.com/iilness2/practical-way-to-use-aws-glue-with-postgresql-1887</guid>
      <description>&lt;p&gt;AWS Glue is an event-driven, serverless computing platform provided by Amazon as part of Amazon Web Services. It is a computing service that runs code in response to events and automatically manages the computing resources required by that code.&lt;/p&gt;

&lt;p&gt;As a popular ETL service, Glue offers numerous options to connect to various databases, including PostgreSQL, which is a widely-used RDBMS.&lt;/p&gt;

&lt;p&gt;Glue provides several ways to set up ETL (Extract, Transform, Load) processes, as shown below:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fnnksjcg15q9dgyrrk4f3.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fnnksjcg15q9dgyrrk4f3.png" alt="Creating AWS Glue Job"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;With its visual setup, performing ETL tasks becomes much easier.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fmbn40xnmhpsg3uwkphah.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fmbn40xnmhpsg3uwkphah.png" alt="Visual Setup Detail"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;You only need a few clicks to create an ETL job that helps transform data from an S3 input to a PostgreSQL output.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5k7tfwpke99sdnkzo7ge.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5k7tfwpke99sdnkzo7ge.png" alt="Visual Setup Detail2"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;However, this setup has several restrictions because you need to follow all the available options before you can create a properly functioning ETL job.&lt;/p&gt;

&lt;p&gt;If you are looking for more flexibility in configuration, you can consider using a script setup.&lt;/p&gt;

&lt;p&gt;With a script setup, you can connect to your data source or output directly from the script. To do this, switch from the visual setup to the script page as shown below:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fx85homi5ggvlca8d2ia7.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fx85homi5ggvlca8d2ia7.png" alt="Script Page"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;For the code, you can use simple scripts like the following:&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import boto3

# Initialize Glue context and job
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

# Read data from S3
s3_path = 's3://your-S3-REPO/'
datasource = glueContext.create_dynamic_frame.from_options(
    connection_type="s3",
    connection_options={"paths": [s3_path]},
    format="csv",  # Adjust format as necessary
    format_options={"withHeader": True, "separator": ","}
)

datasource.printSchema()

# Transform data if needed (this is a simple pass-through in this example)
transformed = ApplyMapping.apply(
    frame = datasource, 
    mappings = [
        ("id", "string", "id", "int"),
        ("name", "string", "name", "string"),
        ("age", "string", "age", "int")
    ]
)

transformed.printSchema()

# Write data to PostgreSQL
glueContext.write_dynamic_frame.from_options(
    frame = transformed,
    connection_type = "postgresql",
    connection_options = {
        "url": "jdbc:postgresql://your-PostgresqlDB-Endpoint",
        "dbtable": "your_table",
        "user": "your-Posgresql-User",
        "password": "your-Posgresql-Password"
    }
)

# Commit the job
job.commit()


&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;And for the input, you can use a CSV format file like this:&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;

id,name,age
1,John Doe,30
2,Jane Smith, 15
3,Bob Yellow,20
4,Roshan Brown,18
5,Bam Black,55


&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;After that, you can start the job and wait until it finishes. If it succeeds, as shown below:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F2tkr88e38s4y2rxif7s3.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F2tkr88e38s4y2rxif7s3.png" alt="AWS Glue Job Status"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;you can check the latest result in your posgresql.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>beginners</category>
      <category>tutorial</category>
      <category>aws</category>
      <category>etl</category>
    </item>
    <item>
      <title>My Perspective on the Latest Improvements in Amazon Inspector from re:Invent 2023</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Sat, 27 Jan 2024 19:04:55 +0000</pubDate>
      <link>https://forem.com/aws-builders/latest-improvements-in-amazon-inspector-from-reinvent-2023-from-my-perspective-32c2</link>
      <guid>https://forem.com/aws-builders/latest-improvements-in-amazon-inspector-from-reinvent-2023-from-my-perspective-32c2</guid>
      <description>&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F4z7wcoiimj07ae18iftn.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F4z7wcoiimj07ae18iftn.png" alt="Image description" width="800" height="415"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h1&gt;
  
  
  Introductions
&lt;/h1&gt;

&lt;p&gt;In the recent re:Invent 2023, AWS made significant improvements to Amazon Inspector, adding features such as agentless vulnerability assessments for Amazon EC2 and expanding AWS Lambda code scanning with AI-powered remediation. These changes position Amazon Inspector as a strong contender for a leading security tool. As a DevSecOps enthusiast, I'm especially excited about its improved integration with CI/CD pipelines for container image assessments.&lt;/p&gt;

&lt;p&gt;This latest update fits perfectly with the basic idea of DevSecOps.  In DevSecOps, we follow a 'shift-left' approach to security. This means we add security measures early in the development process. It helps us catch problems and mistakes earlier, making our development work better and faster. If you want to learn more about DevSecOps, you can find more information &lt;a href="https://dev.to/iilness2/perspectives-on-the-evolution-of-devsecops-engineering-based-on-from-my-experiences-21me"&gt;here&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;For the latest updates on Amazon Inspector itself, there are some features that deserve our attention and consideration:&lt;/p&gt;

&lt;h2&gt;
  
  
  Seamless Integration with Jenkins and TeamCity Through Plugins
&lt;/h2&gt;

&lt;p&gt;In organizations using CI/CD, tools like Jenkins and TeamCity are popular choices for integrating into development lifecycles. Recent native plugins now make it easy for those already using Jenkins and TeamCity to incorporate Amazon Inspector seamlessly. This streamlined integration brings a significant change for these organizations, providing more tool choices to enhance their DevSecOps practices and strengthen their security posture.&lt;/p&gt;

&lt;h2&gt;
  
  
  Generate SBOM with Amazon Inspector
&lt;/h2&gt;

&lt;p&gt;We typically use a Software Bill of Materials (SBOM) to create a list of all open-source and third-party software components in our codebase, services, or applications.&lt;/p&gt;

&lt;p&gt;In the latest update, Amazon Inspector helps us generate SBOMs to simplify our understanding of the installed software composition inside our container images.&lt;/p&gt;

&lt;p&gt;The composition result report will be available in formats like CycloneDX 1.4 and SPDX 2.3, conveniently presented in JSON format, and can be accessed in the S3 bucket.&lt;/p&gt;

&lt;h2&gt;
  
  
  Understand finding better with amazon inspector
&lt;/h2&gt;

&lt;p&gt;Understanding our security is crucial, and having an informative dashboard is a blessing. In the latest update, Amazon Inspector has a dashboard that will help display all the issues detected in our system.&lt;/p&gt;

&lt;p&gt;In Amazon Inspector, a "finding" is a detailed report that reveals vulnerabilities affecting AWS resources. These findings contain important information like the vulnerability's name, severity rating, details about the affected resource, and step-by-step instructions for fixing the issues.&lt;br&gt;
The findings are systematically categorized as follows:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Active Findings:&lt;/strong&gt; These are vulnerabilities identified by Amazon Inspector but not yet remediated. They are subject to suppression rules for efficient management.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Suppressed Findings:&lt;/strong&gt; Meeting specific criteria outlined in suppression rules, these findings are strategically hidden. They remain accessible only within the Suppressed findings list.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Closed Findings:&lt;/strong&gt; Once a vulnerability is successfully addressed, Amazon Inspector automatically marks the finding as closed. These closed findings are efficiently managed and automatically purged after a 30-day period.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This structured approach in Amazon Inspector helps manage vulnerabilities effectively, offering clear insights into the status of each issue and making the remediation process more efficient.&lt;/p&gt;

&lt;h1&gt;
  
  
  Conclusion
&lt;/h1&gt;

&lt;p&gt;With the latest updates from re:Invent 2023, Amazon Inspector has become a stronger and more complete security solution. It now integrates better with developer tools for securing container images, and additional improvements such as agentless assessments in EC2 (Infra part) and utilizing generative AI for remediation in Lambda Code make it even more appealing.&lt;/p&gt;

&lt;p&gt;The ease of integration with CI/CD makes Amazon Inspector even more useful, helping organizations improve their security and DevSecOps practices.&lt;/p&gt;

&lt;p&gt;Stay tuned for more articles where I'll explain how to use Amazon Inspector in CI/CD pipelines for DevSecOps. I'm excited to share insights on its real-world impact and effectiveness, contributing to better security practices in DevSecOps in general.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article comparison. Leave a comment below about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>cybersecurity</category>
      <category>devops</category>
      <category>news</category>
    </item>
    <item>
      <title>My Perspective on the Latest Improvements in Amazon Inspector from re:Invent 2023</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Sat, 27 Jan 2024 19:01:18 +0000</pubDate>
      <link>https://forem.com/iilness2/latest-improvements-in-amazon-inspector-from-reinvent-2023-from-my-perspective-291n</link>
      <guid>https://forem.com/iilness2/latest-improvements-in-amazon-inspector-from-reinvent-2023-from-my-perspective-291n</guid>
      <description>&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F4z7wcoiimj07ae18iftn.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F4z7wcoiimj07ae18iftn.png" alt="Image description" width="800" height="415"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h1&gt;
  
  
  Introductions
&lt;/h1&gt;

&lt;p&gt;In the recent re:Invent 2023, AWS made significant improvements to Amazon Inspector, adding features such as agentless vulnerability assessments for Amazon EC2 and expanding AWS Lambda code scanning with AI-powered remediation. These changes position Amazon Inspector as a strong contender for a leading security tool. As a DevSecOps enthusiast, I'm especially excited about its improved integration with CI/CD pipelines for container image assessments.&lt;/p&gt;

&lt;p&gt;This latest update fits perfectly with the basic idea of DevSecOps.  In DevSecOps, we follow a 'shift-left' approach to security. This means we add security measures early in the development process. It helps us catch problems and mistakes earlier, making our development work better and faster. If you want to learn more about DevSecOps, you can find more information &lt;a href="https://dev.to/iilness2/perspectives-on-the-evolution-of-devsecops-engineering-based-on-from-my-experiences-21me"&gt;here&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;For the latest updates on Amazon Inspector itself, there are some features that deserve our attention and consideration:&lt;/p&gt;

&lt;h2&gt;
  
  
  Seamless Integration with Jenkins and TeamCity Through Plugins
&lt;/h2&gt;

&lt;p&gt;In organizations using CI/CD, tools like Jenkins and TeamCity are popular choices for integrating into development lifecycles. Recent native plugins now make it easy for those already using Jenkins and TeamCity to incorporate Amazon Inspector seamlessly. This streamlined integration brings a significant change for these organizations, providing more tool choices to enhance their DevSecOps practices and strengthen their security posture.&lt;/p&gt;

&lt;h2&gt;
  
  
  Generate SBOM with Amazon Inspector
&lt;/h2&gt;

&lt;p&gt;We typically use a Software Bill of Materials (SBOM) to create a list of all open-source and third-party software components in our codebase, services, or applications.&lt;/p&gt;

&lt;p&gt;In the latest update, Amazon Inspector helps us generate SBOMs to simplify our understanding of the installed software composition inside our container images.&lt;/p&gt;

&lt;p&gt;The composition result report will be available in formats like CycloneDX 1.4 and SPDX 2.3, conveniently presented in JSON format, and can be accessed in the S3 bucket.&lt;/p&gt;

&lt;h2&gt;
  
  
  Understand finding better with amazon inspector
&lt;/h2&gt;

&lt;p&gt;Understanding our security is crucial, and having an informative dashboard is a blessing. In the latest update, Amazon Inspector has a dashboard that will help display all the issues detected in our system.&lt;/p&gt;

&lt;p&gt;In Amazon Inspector, a "finding" is a detailed report that reveals vulnerabilities affecting AWS resources. These findings contain important information like the vulnerability's name, severity rating, details about the affected resource, and step-by-step instructions for fixing the issues.&lt;br&gt;
The findings are systematically categorized as follows:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Active Findings:&lt;/strong&gt; These are vulnerabilities identified by Amazon Inspector but not yet remediated. They are subject to suppression rules for efficient management.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Suppressed Findings:&lt;/strong&gt; Meeting specific criteria outlined in suppression rules, these findings are strategically hidden. They remain accessible only within the Suppressed findings list.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Closed Findings:&lt;/strong&gt; Once a vulnerability is successfully addressed, Amazon Inspector automatically marks the finding as closed. These closed findings are efficiently managed and automatically purged after a 30-day period.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This structured approach in Amazon Inspector helps manage vulnerabilities effectively, offering clear insights into the status of each issue and making the remediation process more efficient.&lt;/p&gt;

&lt;h1&gt;
  
  
  Conclusion
&lt;/h1&gt;

&lt;p&gt;With the latest updates from re:Invent 2023, Amazon Inspector has become a stronger and more complete security solution. It now integrates better with developer tools for securing container images, and additional improvements such as agentless assessments in EC2 (Infra part) and utilizing generative AI for remediation in Lambda Code make it even more appealing.&lt;/p&gt;

&lt;p&gt;The ease of integration with CI/CD makes Amazon Inspector even more useful, helping organizations improve their security and DevSecOps practices.&lt;/p&gt;

&lt;p&gt;Stay tuned for more articles where I'll explain how to use Amazon Inspector in CI/CD pipelines for DevSecOps. I'm excited to share insights on its real-world impact and effectiveness, contributing to better security practices in DevSecOps in general.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article comparison. Leave a comment below about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>cybersecurity</category>
      <category>devops</category>
      <category>news</category>
    </item>
    <item>
      <title>Perspectives on the Evolution of DevSecOps Engineering Based on from My Experiences</title>
      <dc:creator>andre aliaman</dc:creator>
      <pubDate>Sat, 21 Oct 2023 07:47:35 +0000</pubDate>
      <link>https://forem.com/iilness2/perspectives-on-the-evolution-of-devsecops-engineering-based-on-from-my-experiences-21me</link>
      <guid>https://forem.com/iilness2/perspectives-on-the-evolution-of-devsecops-engineering-based-on-from-my-experiences-21me</guid>
      <description>&lt;h1&gt;
  
  
  Introduction
&lt;/h1&gt;

&lt;p&gt;In the rapidly evolving domain of software development, ensuring the security of applications and systems is a top priority. And that's where DevSecOps steps onto the stage, building upon the foundations of the already well-known DevOps. &lt;/p&gt;

&lt;p&gt;As a DevOps Engineer, the evolution of DevSecOps has a significant impact on my role, prompting me to stay vigilant about the configuration and practices in these recent years.&lt;/p&gt;

&lt;h1&gt;
  
  
  Approach
&lt;/h1&gt;

&lt;p&gt;DevSecOps stands for Development, Security, and Operations, where Security become main focus. DevSecOps seamlessly integrates security practices at every step of the development process, promoting a proactive stance toward addressing security concerns early on. Think of it as shifting security "to the left" to align with the continuous integration philosophy that's already a hit in the DevOps world.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Frd7aw4d1b5ur8hkwsbu8.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Frd7aw4d1b5ur8hkwsbu8.png" alt="DevSecOps metric"&gt;&lt;/a&gt;&lt;br&gt;
Traditionally, security checks occur towards the end of the software development process, leaving applications exposed to vulnerabilities that may only surface once the code is finalized. DevSecOps, however, paves a different path. It incorporates security checks right from the beginning of the development process. This approach empowers developers to identify and rectify security issues at the outset, significantly reducing the likelihood of costly and time-consuming fixes in the later stages of development.&lt;/p&gt;

&lt;p&gt;To make DevSecOps seamless and effective, a range of new stages are introduced within the Continuous Integration (CI) pipeline. These stages are dedicated to unearthing vulnerabilities, threats, and risks that may be lurking within the application. By implementing these strategies, DevSecOps not only fortifies software systems against malicious threats but also lays the foundation for a safer and more resilient software development journey.&lt;/p&gt;

&lt;p&gt;As part of this journey, DevSecOps incorporates various security testing practices into the CI pipeline. Let's delve into a few of these:&lt;/p&gt;

&lt;h2&gt;
  
  
  Software Composition Analysis (SCA)
&lt;/h2&gt;

&lt;p&gt;In the world of software development, applications often depend on third-party or open-source components for their functionality. SCA, short for Software Composition Analysis, is your digital detective for tracking these dependencies and ensuring they don't introduce vulnerabilities into your software.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;How Does SCA Work?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;SCA scans your application, scrutinizing both the source code and binary files, to uncover any known vulnerabilities lurking within the third-party or open-source components. When these vulnerabilities are spotted, it's not a cause for alarm. In many cases, a remedy exists, and it's as simple as applying a patch or upgrading to the latest version of the affected third-party libraries.&lt;/p&gt;

&lt;p&gt;But SCA's capabilities don't stop there. It can also raise a flag when it stumbles upon any unknown or altered components within your application. This additional layer of scrutiny empowers you to identify and investigate unfamiliar elements that might be lurking in your software.&lt;/p&gt;

&lt;h2&gt;
  
  
  Code Quality Scanning
&lt;/h2&gt;

&lt;p&gt;Code quality scanning is a practice within DevSecOps that involves a meticulous examination of your source code to assess its structural integrity, adherence to coding standards, readability, in short is the quality and also check the complexity of the code. It serves as an early warning system for issues, promotes better coding practices, improves collaboration, enhances software quality, and aligns with the principles of DevSecOps, where security and quality is integrated into the development process from the outset.&lt;/p&gt;

&lt;h2&gt;
  
  
  Static Application Security Testing (SAST)
&lt;/h2&gt;

&lt;p&gt;SAST, or Static Application Security Testing, is a crucial security practice in software development. It involves a thorough examination of your source code, reviewing it without executing the code. The primary goal of SAST is to identify and flag known vulnerabilities or security issues in your codebase. It does this by analyzing the code's structure, logic, and patterns, searching for coding mistakes, misconfigurations, or vulnerabilities that are well-documented and recognized within the security community.&lt;/p&gt;

&lt;p&gt;In essence, SAST is like a code grammar and spell-check for security. It helps you identify and rectify issues early in the development process, before the application is even run or tested. This proactive approach is critical for ensuring the security of your software, as it allows developers to fix vulnerabilities at an early stage, reducing the risk of security breaches and the cost of addressing issues later in the development lifecycle. SAST not only helps in building more secure software but also promotes security awareness among developers, making it an essential tool in the realm of DevSecOps.&lt;/p&gt;

&lt;h2&gt;
  
  
  Dynamic Application Security Testing (DAST)
&lt;/h2&gt;

&lt;p&gt;Dynamic Application Security Testing (DAST) is a crucial security practice, especially for web applications. It works by actively testing your application while it's running in a real-world environment.&lt;/p&gt;

&lt;p&gt;Imagine deploying your web application to a new environment like a production server. During this process, your application may be exposed to new security risks that were not apparent in the code. For instance, you might encounter misconfigurations or incorrect security assumptions that only become evident when the application is running.&lt;/p&gt;

&lt;p&gt;DAST acts like a real attacker, probing your live web application to identify vulnerabilities that might not be visible during code review or static analysis. It helps ensure your application's security in the real world, beyond just the development phase. In short, DAST is crucial for uncovering and addressing security issues that may emerge as your application moves from development to deployment.&lt;/p&gt;

&lt;h1&gt;
  
  
  Conclusion
&lt;/h1&gt;

&lt;p&gt;In conclusion, DevSecOps stands as a robust and proactive approach to software development. By integrating security practices throughout the development process and implementing comprehensive security testing measures, DevSecOps ensures that software is not only secure but also of the highest quality. This philosophy fosters a culture of continuous improvement and a commitment to delivering secure, reliable, and resilient software to meet the ever-evolving challenges of the digital landscape.&lt;/p&gt;

&lt;p&gt;I think that's it for now for this article. Leave a comment below. So, I know about your thoughts! Thanks.&lt;/p&gt;

</description>
      <category>beginners</category>
      <category>devops</category>
      <category>softwaredevelopment</category>
      <category>cicd</category>
    </item>
  </channel>
</rss>
