Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Recently, we released the JVM Ecosystem Report 2021. This annual report is full of interesting facts about the current state of the Java ecosystem. If you haven’t seen it yet, you should give it a read. Don’t forget to download the full PDF for all the insightful information.

In the first part of this blog series, we looked at security best practices for the base images which you might be using. But what happens to container image security when we add other things to it? Perhaps we’re installing additional software from upstream, and we’ve got custom applications of our own which might have their own dependencies also being installed.

With DevOps teams moving at ever greater speed, it’s vital for security teams to be deeply involved at all stages of the software development and delivery lifecycle. Breaking down silos between development, operations, and security teams ensures that security considerations are not overlooked, that vulnerabilities are caught early, and that security checkpoints do not slow down the delivery process.

If you’re doing open source development today, chances are high that you’re active within the GitHub community — participating in open source projects and their repositories. A recent addition to the GitHub ecosystem is GitHub Packages, which was announced back in 2019 and is now receiving even more updates with the general availability of the GitHub Packages container registry.

In Kubernetes, the task of scheduling pods to specific nodes in the cluster is handled by the kube-scheduler. The default behavior of this component is to filter nodes based on the resource requests and limits of each container in the created pod. Feasible nodes are then scored to find the best candidate for the pod placement. In many scenarios, scheduling pods based on resource constraints is a desired behavior.

This is a guest blog post from Shuo Yang in his blog series “Transitioning to Programming the Cloud”, as a part of our blog posts focusing on Identity, Security and Access. We talked about how AWS CIP, STS and IAM can serve as the foundation of application authorization in our last post, i.e., how the application gets the temporary credential representing a specific role (i.e.