![](\"https:\/\/www.trendmicro.com\/content\/dam\/trendmicro\/global\/en\/devops\/22\/b\/a-cloud-native-application-protection-platform-guide\/c-napp.jpg\")
<\/p>\n<\/p>\n
<\/div>\n5 key components to review<\/span><\/p>\n To ensure secure apps are developed and deployed, McCluney and Griffin recommend implementing review processes for the following:<\/p>\n Before delving into each of these components, let\u2019s review why each one is key, and understand how the state of the industry has shaped these key security components.<\/p>\n 4 cloud native development trends<\/span><\/p>\n McCluney and Griffin point to 4 emerging cloud-native trends as indicators of the 5 key security focuses:<\/p>\n Containerization and container sprawl Why the rise in popularity? Thanks to their portability across platforms and small size, it is ideal for modern DevOps, serverless, or microservices application architects that are built in small chunks for better efficiency.<\/p>\n Infrastructure as code (IaC) Considered one of the most important DevOps practices, IaC provides real benefits for developers who need to build quickly and securely in the cloud; they can now deliver multiple test environments reliably and on-demand in any type of cloud workload or architecture.<\/p>\n If you\u2019re running serverless or containerized applications, IaC accelerates the release cycle, freeing you from mundane, repetitive tasks, and reduces potential misconfigurations due to human error.<\/p>\n Microservices For teams building in the cloud, microservices allows developers to work on their assigned components using the programming language and tools of their choice. This flexibility increases agility, reduces time to market, and accelerates your CI\/CD pipeline.<\/p>\n It also simplifies app changes or fixes. With microservices, you only have to make changes to the applicable component, compared to a monolithic app, which requires you to implement the change across the entire app. Sounds time-consuming, right?<\/p>\n Serverless How to review the 5 key cloud security components<\/span><\/p>\n Okay, now that we\u2019ve discussed the why, let\u2019s return to the 5 key components to review for secure apps.<\/p>\n Cloud posture and compliance The rules and regulations that can haunt SecOps teams are there to double, triple, quadruple check you\u2019re actually<\/i> building apps that can keep troves of data secure.<\/p>\n However, meeting compliance requirements isn\u2019t just a task for security teams. Developers also play a part. As cloud builders, leveraging the AWS Well-Architected Framework<\/a> or similar guides ensures you\u2019re meeting compliance standards.<\/p>\n As Griffin explained, you wouldn\u2019t just apply your deodorant on Monday and expect it to last the week; the same concept applies to meeting and maintaining compliance<\/i>. Compliance and cloud posture management isn\u2019t a one-time ordeal. As technology progresses, and compliance follows suit, your app security must evolve and adapt.<\/p>\n How can you achieve continual compliance? According to Griffin: a CSPM security tool that provides comprehensive visibility and quick observability.<\/p>\n A cloud native security platform provides a dashboard for visibility across your entire, fast-changing environment and at-a-glance insight into your alignment to frameworks and compliance standards.<\/p>\n With enhanced vulnerability visibility, security teams can identify areas of improvement for developers before it\u2019s too late.<\/p>\n Vulnerability visibility and management Griffin notes that visibility into your open source code is paramount to vulnerability management. Is your code trusted? To answer that, you need a full understanding of its dependencies and libraries.<\/p>\n Okay, maybe you<\/i> don\u2019t need to know that information like the back of your hand, but you do need a cloud native security platform that can run the necessary scans to give your code the greenlight.<\/p>\n By greenlight we mean you should scan code before<\/i> it\u2019s deployed, so your workloads are essentially born secure. This practice is part of starting left, which enables secure and quick app development.<\/p>\n Access and credential management is also important. If they\u2019re leaked out in the code you\u2019ve written, which is then exposed to a public repo, you\u2019ve exposed opened your entire environment to vulnerabilities.<\/p>\n Griffin said he often hears the line: \u201cThat\u2019s just my dev account,\u201d in response to access management. Whether it\u2019s your dev account or not, it\u2019s still a public account within a cloud platform, and therefore requires the same security boundaries.<\/p>\n Back to the important of visibility. You have too many accounts to keep track of manually, but a cloud native security platform can provide visibility into everything in one dashboard. From there, you can manage access to active and dormant accounts (just because it\u2019s closed to you, doesn\u2019t mean it\u2019s closed to vulnerabilities).<\/p>\n To summarize, to be able to stop vulnerabilities, you need to see them. And to be able to see them, you need to see every entrance point like open source code, keys, containers, and accounts. And to be able to see every entrance point, you need a unified platform that consolidates all that information into one dashboard for quick observability.<\/p>\n Container security Container sprawl isn\u2019t the only security issue; using insecure images, running with the privileged flag, and unrestricted communication are chief among others. Also, keep in mind that even if a container was deemed secure yesterday, that could quickly change by tomorrow.<\/p>\n The need for comprehensive visibility within a platform strikes again. Being able to see all your containers from one place can help wrangle in the ones gone rogue and limit sprawl. Moreover, it can drastically reduce misconfigurations (the #1 cause of data breaches). The danger of misconfigurations mean you must<\/i> have security practices in place to ensure you\u2019re properly configuring container images, secrets, runtime privileges, and networks policies to name a few.<\/p>\n You can avoid misconfigurations by running automated scans across all<\/i> your containers to validate images before<\/i> they land and check for any overly permissive or open containers.<\/p>\n By leveraging a platform with runtime application self-protection (RASP) capabilities, the platform can learn the expected behaviors (i.e., network communication) of the containers, before they\u2019re set to live. This ensures that when the containers are switched to live, any changes in learned behavior will be detected or blocked and security teams will be immediately notified.<\/p>\n IaC Template Scanning This is largely due to the notion that after you\u2019ve established a secure template, it\u2019s going to stay that way and you can deploy at will. However, if you\u2019ve changed the template to public\u2014let\u2019s say for internal security testing\u2014and you forget to close it, the next time you deploy it, the vulnerability is wide open.<\/p>\n Secure secret storage is critical; if you accidentally publicize your IaC, application tokens necessary for authentication, Secure Shell (SSH) keys, and passwords are now exposed and ready for the taking. If you\u2019re storing secrets in source code management (SCM) systems or plain text files, this makes it even easier for bots that scrap public SCM sites to quickly exploit them and compromise the infrastructure.<\/p>\n Also, tracking and traceability can be challenging the more widely used the template is across multiple teams. That\u2019s why scanning templates before<\/i> deployment is critical. And having visibility via a platform can ensure all your templates\u2019 code meets compliance requirements and is configured properly.<\/p>\n Securing your code Think of your code as the ingredients for a tasty beef stew. If you use expired meat, you\u2019re most likely going to get food poisoning. Similarly, if you use unchecked open source code, your app is most likely at risk for an attack.<\/p>\n Thus, it\u2019s important to always check the expiry date of your meat\u2014or in this case, the dependencies and libraries of your open source code. Many open source projects have other open source dependencies, which may also have their own dependencies, which may also\u2026 You get the picture. This never-ending chain of dependencies may introduce new and undetected vulnerabilities into your workloads.<\/p>\n Also, open source code libraries typically require manual updating, which is understandably hard to track and manage, especially considering the sheer number of components embedded in your app.<\/p>\n To make open source code management easier, an automated platform is key. By automating open source code scans (starting before<\/i> code is committed), vulnerabilities can be surfaced and monitored quickly, allowing security teams to proactively mitigate potential risks before the app is exploited. In the best case scenario, scanning the code at the start, prevents vulnerabilities from ever reaching the production environment.<\/p>\n Next steps<\/span><\/p>\n A cloud native security platform is essential to covering these 5 security components. If you\u2019re interested in learning more about Trend Micro Cloud One\u2122<\/a>, our cloud-native security platform composed of 7 services, you can check out our extensive documentation<\/a>. You can also start a free, 30-day trial and see how our security services platform can review the 5 security components using turnkey, customizable APIs, automation, and more.<\/p>\n\n
<\/b>Griffin pointed out that years ago, containerization was started by developers just playing around with different storage methods. Years later, cloud-native apps are running and breathing on containers.<\/p>\n
<\/b>Like containers IaC<\/a> isn\u2019t anything new, but it\u2019s becoming the go-to method for deploying app environments.<\/p>\n
<\/b>Say good-bye to monolithic apps and hello to a microservices architecture<\/a>. Whereas a monolithic app is a single, unified unit, the microservices architecture breaks down the app into independent components.<\/p>\n
<\/b>The move to the cloud has also led to the adoption of serverless computing. Just as the name suggests, you no longer need to rely on physical servers to host your apps. Now, you can rely on third-party services like AWS Lambda<\/a> to manage the physical hardware, virtual machine operating system, etc., while you worry about managing your code.<\/p>\n
<\/b>Ah, compliance, the necessary evil. Without compliance, you\u2019re at risk for a breach. And without proper cybersecurity policies, controls, and standards, you\u2019re at risk of breaking compliance.<\/p>\n
<\/b>You\u2019ll notice that visibility is a common theme here. And for good reason. Vulnerabilities aren\u2019t going anywhere\u2014Apache Log4j (Log4Shell)<\/a> is proof of that. Griffin speculated there are more than 50,000 vulnerabilities in the CVE database with a critical or high-severity rating. But you can\u2019t stop what you don\u2019t see, hence the importance of visibility.
<\/b><\/p>\n
<\/b>As containers become more popular, container sprawl is an emerging security concern. Defined as<\/a> \u201cthe tendency to run up an unnecessary number of containers,\u201d container sprawl has critical security implications. The more containers you spin up, the harder it is to keep track of efficiency issues.<\/p>\n
<\/b>IaC is being widely adopted because it supports the agile practices of modern app development. However, Griffin noted that securing IaC is \u201cone of the most overlooked areas for security management.\u201d<\/p>\n
<\/b>We\u2019ve mentioned code quite a bit already, so it might seem like overkill to go through it again. Key word: seem. Securing your code is so important, we will never stop saying it. And with 80% of code being open source<\/a>, it needs to be screamed from the mountaintops with a megaphone.<\/p>\n