secret scanning is a must

-

 Shifting as much security as we can to the Left

Imagine taking multiple platforms, public, private, CI platforms such as GitLab, Travis, Jenkins, etc., and quickly ingesting into one landing page code scanning, image scanning, and even infrastructure as a code scanning you can easily manage and operationalize. 

You can centrally locate and report on all your findings and report with a landing page made for you regardless of where the build or development is happening. No need to change CI platforms or providers. It just works. 

Local and Public Build Servers, Runners. Developer only, cool. Developer and Operations, cool, Security and Compliance only excellent. Most of us wear many hats, and your platform should adapt accordingly.

Have a single landing page to review, report, or get an idea of the big picture flow... Interested, keep scrolling


You may develop locally, using build servers, cloud platforms, bastion hosts, or whatever you use or call it, it doesn't matter. 

What does matter is that these details can provide insight into the bigger picture. You don't have to change what or how you are doing things, just put a ring (-flag) on it :) send it back to the Platform to share out, follow up, report, and assimilate into a workflow processing beyond slack or teams. 

These are my most exciting areas of concern for me, and as you can see from the dashboards I created, I wear many hats. Remember that these widgets within the dashboard can be further drilled into. They take you to the secret, malicious file, compliance details, vulnerability, remediation instructions, which package or distro is needed, etc. 

So many ways and so many technologies. Though there are many ways to organize the areas you are most concerned with, I think you will get the idea. If you can dream it, you can do it! 

Snippets of Platform Widget and Dashboard Capabilities:
















Widgets of, Operational, Pipeline, Compliance, and others









There are many predefined dashboards (as below) to get started right away. Or clone it, build on or make your own! 

Developer & Pipeline, and Deployment: 

You can visit our quick integration and support guide. Just so you know, Check Point acquired Spectral, and although the technology is already built into our platform, I reference the original docs for now.

Technical Docs: Visit the Admin Guide

If you would like more info on our shifting left solution in general, you can visit the official product page.



Popular

Federated user activity made easy

-
Image
 Federated user activity made easy. The other day I was auditing a sandboxed account in AWS and started investigating resources connected to a federated role for a group of students that are no longer enabled on the account. I noticed a few objects that should have been elsewhere or terminated after the fact, regardless, neither here nor there. After about 30 minutes of sifting through logs, creating custom queries, and trying to put them together, I lost interest because of the time and day-to-day priorities. I felt this was a good use case for me to test out some of the functionality of CloudGuard's investigation and correlation engine within the platform and try out this voice-over platform. Enjoy - Video below: if you feel inclined to research further, visit the product page
Read more

Meet Kaniko

-
Image
So, what is kaniko? Kaniko is a tool to build container images from a Dockerfile inside a container or Kubernetes cluster. Another great callout for me is that my CI provider, GitLab makes it super easy to implement in my pipelines. Kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile entirely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster. How does Kaniko work? The kaniko executor image is responsible for building an image from a Dockerfile and pushing it to a registry. Within the executor image, we extract the filesystem of the base image (the FROM image in the Dockerfile). We then execute the commands in the Dockerfile, snapshotting the filesystem in userspace after each one. After each command, we append a layer of changed files to the base image (if there are any) and update image metadata. Highly recommend visiting their  repo  ...
Read more

Google Cloud: Container Registry will be replaced by Artifact Registry

-
Spoiler Alert: (you've got some time) Container Registry will be replaced by Artifact Registry. Please upgrade your projects to Artifact Registry before March 18, 2025. On March 18, 2025 , Container Registry will be replaced by Artifact Registry . We understand this change may affect your production workloads, so we've put together resources to make this transition as smooth as possible for you. What do you need to know? To retain access to your container images, please take note of these critical dates and actions you need to take related to the Container Registry shutdown: March 18, 2025: You will no longer be able to push new images to Container Registry. April 22, 2025: You will lose access to existing images in Container Registry. To maintain access, you must copy them to the Artifact Registry before this date. May 22, 2025: All requests to the gcr.io domain will be handled exclusively by Artifact Registry. Ensure the Artifact Registry...
Read more