staging-devopsy.kinsta.cloud

Tag: devsecops

  • Codenotary Uses Immutable Database to Verify Software Artifacts

    Codenotary Uses Immutable Database to Verify Software Artifacts

    Codenotary today unfurled a free notarization and verification service for open source artifacts and containers to enable IT organizations to track the provenance of the components that make up their applications.

    Dennis Zimmer, Codenotary CTO, said the Community Attestation Service is based on an immutable open source immudb database that cryptographically attaches an identity to each software artifact. Additionally, the Community Attestation Service can be integrated with the continuous integration/continuous delivery (CI/CD) platform that DevOps teams employ to build and deploy applications using those artifacts, added Zimmer.

    The identities created by the Community Attestation Service can then be used to verify a software bill of materials (SBOM) that will soon be required by not only every U.S. federal agency but also organizations that are trying to better secure their software supply chains in the wake of a series of high-profile breaches, said Zimmer. The Community Attestation Service will also encourage developers to reuse source code, builds, repositories and Docker container images that they know they can reliably employ within a zero-trust IT environment, noted Zimmer.

    Some developers have, of course, been signing their code for years, while others simply didn’t see the need. With its free service, Codenotary is trying to expand the pool of developers that will not only sign their code but do so in a way that can’t be tampered with later, noted Zimmer.

    Unlike blockchain databases that are employed to provide immutable records of transactions, Zimmer said the immudb platform was created to provide an immutable database capable of processing millions of transactions per second. That database is also being used to build a wide range of applications that go beyond the scope of the Community Attestation Service so DevOps teams can have confidence in the viability of the underlying platform, noted Zimmer.

    In the wake of some troubling security breaches, it’s now only a matter of time before security teams start to ask more difficult questions about how applications are built. Developers could wait for those cybersecurity teams to eventually create policies that DevOps teams would be required to enforce, or they can more proactively embrace a service that tracks the provenance of code that hopefully, has been scanned for all known vulnerabilities. In fact, it may not be too long before organizations decide not to employ code that has not been verified. There may even be a backlash against using code that is unsigned that could result in many existing applications either being updated or outright replaced.

    On the plus side, Zimmer noted there’s a lot more awareness of the need to sign code. The challenge is most organizations don’t have the processes in place. Fortunately, there’s a lot more interest in DevSecOps best practices to ensure the integrity of code. However, awareness of the need for something doesn’t always result in concrete actions being taken unless DevOps teams can simply make it easy for developers to do the right thing. After all, it’s not as though developers want to employ insecure code, it’s just that they are often simply too busy to make sure every last artifact employed is verified as secure.

  • Authentication in Serverless Apps—What Are the Options?

    Authentication in Serverless Apps—What Are the Options?

    Serverless applications are growing in popularity among DevOps engineers. They provide a convenient, predictable way to run simple processes like CI/CD builds or automation scripts with no need to stand up infrastructure. They are also commonly used to deploy microservices. However, serverless applications present unique security challenges, one of them being authentication. 

    How can you ensure services communicate with other services or with the outside world only if authorized to do so? How can you ensure users can conveniently and securely access multiple instances of a serverless function?

    In serverless applications, there are many components interacting—not only end users and applications but also cloud vendors and applications. This is why common authentication methods, such as single factor, two-factor and multifactor authentication offer only a bare minimum foundation. Serverless authentication requires a zero-trust mentality—no connection should be trusted, even communication between internal components of an application should be authenticated and validated.

    To properly secure serverless authentication, you also need to use authentication and authorization protocols, configure secure intraservice permissions and monitor and control incoming and outgoing access. In this article, I’ll cover all these briefly and demonstrate a practical example—setting up authentication in the AWS serverless ecosystem.

    What Are the Most Common Authentication Methods?

    Here is an outline of the standard authentication methods used by most applications.

    Single-Factor Authentication

    Also called primary authentication, this is the most prevalent and straightforward type of authentication. Single-factor authentication asks for only one authentication method; for example, a security PIN, password or PIV card, to gain access to a service or system.

    These methods are solid in relation to familiarity and usability; however, they are generally linked to poor security and credentials can readily be stolen or guessed through phishing, data breaches or by using keyloggers.

    Two-Factor Authentication

    Two-factor authentication (2FA) adds another layer of intricacy, as it needs an additional factor to authenticate a user’s identity. Common verification methods include one-time passwords, tokens created by a registered device or PIN numbers. The presence of two verification methods significantly improves your level of security. 

    Multifactor Authentication

    This is the most complex process of authentication. It makes use of two or more independent factors to verify a user’s identity and authorize access to the system. In common scenarios, multifactor authentication (MFA) makes use of at least two of the following factors:

    • A PIN or password (something known)
    • Security token or mobile phone (something owned)
    • FaceID or fingerprint (something you are)
    • Location information, typing speed or the like (something you can do) 

    Authentication and Authorization Protocols

    An authentication protocol is a communication protocol that protects authentication data as it transfers between two entities. It enables a receiving entity to authenticate a connecting entity as well as authenticate itself to a connecting entity. This is achieved by declaring the type of information required for authentication and syntax.

    There are several types of authentication and authorization protocols, including:

    • Lightweight Directory Access Protocol (LDAP)—a software protocol that enables anyone to find data about individuals, organizations, and resources like files and devices within a network. LDAP allows this whether a user uses the public internet or a corporate intranet.
    • The Security Assertion Markup Language (SAML)—an open standard that allows sharing security information about authentication, authorization and identity across several different systems. 
    • Open Authorization (OAuth)—an open standard authorization framework designed for token-based authorization established over the internet. OAuth enables third-party services to use end-user account information without exposing user account credentials to the third party. This blog post can help you understand the differences between SAML and OAuth.
    • OpenID—enables authentication services and websites to exchange security information in a standardized manner. OpenID Connect—the newest version of the protocol—provides improved identity management, support for mobile application development, and interoperability. Learn more in the official OIDC FAQ.

    Secure Authentication on Serverless

    In serverless systems, there are four forms of access—four forms of communication that should be secured. An individual service won’t have to include all four, but the categories that it does feature should be well-protected. 

    Intraservice Access

    Creating a system by uniting serverless services has many advantages. However, you should consider the security of every additional service. 

    A service with excess permissions is a liability. Unnecessary permissions provide excessive access to data, actions or services, and a bug might let malicious users exploit that service and use its permissions to endanger your system. Hence, you should give careful consideration to the permissions required by each service.

    Effectively overseeing intraservice access permissions is often an overwhelming job. Luckily, all of the top-tier cloud providers have native access management services to make this task simpler. AWS has AWS IAM, Azure has Azure Active Directory and Google Cloud Platform (GCP) provides Cloud IAM. 

    Incoming Access

    A network is made accessible through a SaaS offering to external users. Access will be restricted, and every user will require the official credentials to achieve that access. 

    However, this brings up the same problems raised above—the secrets must be stored somewhere. You cannot manage how your users access and store the credentials that you provide them with; therefore, you should assume that their credentials are not being kept securely and that they may be compromised at any point.

    This would appear to be an unmanageable issue, but there is a solution—to provide temporary credentials. This means that even if the secrets were revealed, they would expire shortly afterwards. 

    The cloud providers have services for this. Google Cloud IAM offers short-lived credentials, AWS IAM lets you create temporary credentials and Azure Active Directory lets you configure expiration dates for its signatures that have shared access.

    Outgoing Access

    When your organization’s serverless function has access to an external third-party service, it typically needs some sort of access credentials. These credentials need to be kept somewhere, but this storage is sometimes not as secure as it should be. Today, certain web applications continue to store secrets in databases, text files or hardcoded within the function code. 

    Cloud providers have services for securely retaining credentials and secrets. AWS has AWS Secrets Manager, Azure offers Azure Key Vault and GCP offers Google Cloud Secret Manager.

    End User and Customer Access

    The issues with this access type are akin to those for incoming access, though the solution is different. Whether in B2B or (particularly) B2C environments, not many users would put up with a requirement to continuously regenerate or refresh their credentials. Thus, another approach is needed. 

    The top-tier cloud providers all have a user authentication service—Azure Active Directory B2C, AWS Cognito and Google Identity Platform. You should also consider using third-party end-user verification, as this will help you avoid vendor lock-in. Third-party offerings also tend to offer a better developer experience. The most common third-party authentication providers are Okta and Auth0.

    AWS Lambda Authentication Solution Example

    Amazon Cognito offers managed authentication and authorization that can help you build secure web services in a serverless architecture. It is typically used in combination with Amazon API Gateway when building complex serverless applications that require permission control.

    For example, a payroll system may have a manager and two additional employees. The three employees can use their unique usernames and passwords to log into the payroll system—this process is called authentication.

    To retrieve paystubs, the three employees undergo role-based authentication:

    REST API GET /api/employee/{employee_id}/paystubs

    However, the permissions they get through this process should be unique to their needs. This may involve setting up the following conditions:

    • The manager can access the paystubs of all employees.
    • Employees cannot access the paystubs of other employees, only their own. 

    You can use AWS managed services to fulfill the above requirements and also meet future scaling needs.

    Image Source: AWS

    Step One: Setting Up AWS Lambda Authorizer

    The Lambda authorizer is the brain that centrally determines whether the requester has the relevant permissions for the requested API resources.

    Here’s how you can set it up:

    • Navigate to the Amazon API Gateway and create an authorizer.
    • Select the API resources you want to secure and assign the AWS Lambda function to them.
    • Configure your new AWS Lambda authorizer.

    Step Two: Building User Access Control List (ACL)

    It is crucial to establish user permissions and keep them up-to-date. The approach might differ according to your identity provider. Here is an example of the process if you use Amazon Cognito as your IDP. 

    1. Initialize the ACL

    Every user has a unique ID, so you can describe each user’s permissions by inserting items in the permission table in Amazon DynamoDB when you register with Cognito. The DynamoDB permission table stores the access control list for all users, although the implementation may differ based on the use case. 

    For this example, let’s use a single integer ID for each employee (the UUID strings in real applications tend to be much longer). 

    Manager:

    uuid: xxxx-xxx-xxx-xxxx-xxxxxxxx

    employee: {“allow”: [“/5”,”/5/*”]}

    paystubs: {“allow”:[1,2]}

    Employee 1: 

    uuid: xxxx-xxx-xxx-xxxx-xxxxxxxx

    employee: {“allow”: [“/6”,”/6/*”]}

    paystubs: {“allow”:[3,4]}

    Employee 2: 

    uuid: xxxx-xxx-xxx-xxxx-xxxxxxxx

    employee: {“allow”: [“*”],”deny”:[“/7”,”/7/*”]} // employee_id=7 is the manager of employee 2

    paystubs: {“allow”:[1,2,3,4]}

    2. Manage the Access Control List (ACL)

    The user permissions in a complex project are constantly changing. Employees can be promoted, demoted or terminated, with different access requirements depending on their changing roles. A new manager, for example, needs access to all pay stubs, which means you have to create a new pay stub object for every employee. 

    You can manage user permissions using the Amazon DynamoDB stream:

    Lambda functions can easily be integrated when you insert or modify items in the permissions table. A Lambda function might include code that modifies permissions according to changes to the role of a user.

    3. Build an ACL policy

    Once you’ve established an ACL with user permissions for every object, you should create an authorization policy document. The Lambda function authorizer uses this policy to evaluate whether user API requests should be allowed or denied.

    Amazon API Gateway offers a mechanism for evaluating policies internally. internal policy evaluation mechanism. The Gateway will automatically evaluate any policy JSON returned by the authorizer. For details about Lambda authorizer’s output standard, see this document.

    In this article, I covered the basics of authentication in serverless applications:

    • Single-factor authentication
    • Two-factor authentication
    • Multifactor authentication
    • Intraservice access
    • Outgoing access
    • Incoming access
    • A real-life example with Amazon Cognito

    I hope this will be of help as you gain a better understanding of authentication and authorization techniques that help secure serverless applications.

  • Learn a Bit About AI

    Learn a Bit About AI

    Every once in a while, a trend becomes broad enough that I feel the need to offer career advice. This year it will be simple: Know enough about AI/ML to be dangerous. We are past the point where not having at least a basic understanding is a good idea. Looking around the data center, AI is in use from the earliest stages of development through production network performance evaluation. Somewhere in your environment, you are using AI and ML. More to the point, somewhere in the places you may interview going forward, they are using AI and ML.

    I’m not suggesting you become an AI/ML expert—though you certainly could; I have a relative that is a data scientist and that’s all he does—design and tweak algorithms. He’s learning new things pretty much daily, so if you like that (as I do), it’s an option. But for those of us doing DevOps or SRE or even regular old operations, we’re only going to have to understand a bit.

    Understand what tools like Jupyter are, and what the most commonly used ML algorithms in your space are. Then, learn about how AI and ML help with what you are doing. Just as knowing more about the compiler/interpreter of your chosen language helps you solve more odd problems, AI is going to have that same issue. Think about how those folks who understand the guts of routing are the ones we want solving our routing problems. Again, same scenario.

    Moving forward, AIOps, NetOps, DevSecOps … All intend to increase the amount of work offloaded onto the AI in question. In a lot of cases that is great. We have enough to do; if you can paw through those logs and give me relevant summary info, go for it. But it doesn’t end there—some AI engines are making the calls and implementing changes. In both network and application security, a fair number of vendors will tell you there is no time to wait for humans to stop an attack, and they encourage their customers to turn on automated responses. That’s the first of many applications for AI/ML. We will see an increasing number of AI/MLOps tools being used for full-on automation. We all do difficult jobs with a complex—sometimes bewildering—number of inputs. But we use pattern recognition and experience to make determinations and do what’s best for our organization. Our software has reached the point where sometimes, it can do that for us on the easier tasks so we can focus on the more complex ones. When the AI/ML fails—and it will, because pattern recognition and historical trends are not always indicative of normal usage—knowing what is going on under the covers can help you determine if it did the right thing in the wrong way, or simply did the wrong thing. And it can help you to quickly recover. I can’t speak for every organization, but I’ve never seen one that lamented, “Sure wish that outage had lasted another couple of hours!”

    And keep rocking it. Somewhere in the distant future, an  AI may be able to do your job as well as you. But that isn’t today. Even if it can handle one bit, it certainly isn’t rocking the entire breadth of your responsibilities like you are. Thank you, from all the users that don’t realize you’re keeping them live.

  • A Blueprint for Securing Software Development

    A Blueprint for Securing Software Development

    Software development has changed dramatically in recent years, as technologies like DevOps, application containers, and cloud-native transform how software is built and distributed. Unfortunately, attackers have been paying close attention to these changes, and have retooled their attack strategies to take advantage of relatively weak security controls in software development and build environments. Attackers recognize that security teams are more focused on protecting infrastructure and less focused on software development and supply chains. This is how damaging attacks like SolarWinds happen – and it’s likely that attackers will strike again to yield even more successful outcomes.

    A new approach is needed to secure the software development pipeline. What’s more, this approach needs to be put in place by the engineers developing the software—and not by information security teams. Engineering teams need to be responsible for design and implementation while giving security teams visibility and assurance that controls are operational and that policies are being enforced.

    A new blueprint for securing the pipeline centers on a flexible set of controls that secure the software build pipeline by ensuring that authentication and authorization are properly managed, that the integrity of software artifacts are tested at appropriate stages and that controls are placed on third-party and open source solutions incorporated into the software. The result: Software innovation and delivery at lower risk of supply chain tampering, and reduction of attacks during development.

    A Pragmatic Design Philosophy

    This modern software security blueprint is based on the following design philosophy:

    • Least-privilege: Only grant the access and permissions required to accomplish a job, and no more.
    • Immutability: Artifacts and infrastructure are not modified after deployment to an environment. If a change is required, it’s done in the image or script in the development environment and then promoted through the higher environments.
    • Everything-as-code: Infrastructure, security policies and other parts of the pipeline are also implemented as code and subject to the same controls as the software artifacts.
    • Traceability: All changes, whether to infrastructure or business code, are version-controlled. 

    Controls Blueprint for Software Development Pipelines

    The basis for this software security blueprint centers around a set of 15 controls that are built for modern development pipelines where developers, pipelines and execution can happen anywhere in the world.

    Control one: Restrict administrative access to CI/CD tools. Ensure that only authorized people can make administrative changes to the CI/CD system, which prevents unauthorized changes to pipeline definitions.

    Control two: Only accept commits signed with a developer GPG key. Unsigned code commits are challenging, if not impossible, to trace and pose a risk to the integrity of the codebase. 

    Control three: Automation access keys expire automatically. By ensuring that access keys used by automation expire periodically, developers create a shorter window of attack when keys are compromised.

    Control four: Reduce automation access to read-only. CI systems should have read-only access to source code repositories following the principle of least-privilege access.

    Control five: Only dependencies from trusted registries can be used. By configuring the dependency manager to only allow connections to an authorized list of registries, attacks can be blunted by keeping malicious packages in public registries from entering the pipeline.

    Control six: Any critical or high-severity vulnerability breaks the build. Supply chain attacks may introduce code with vulnerabilities into the software pipeline. Static application security testing (SAST) helps to identify serious security issues, including poor cryptographic practices, hard-coded credentials and injection vulnerabilities. 

    Control seven: Artifacts are stored in a repository in development, staging and production. This control helps to enforce the immutability of the artifacts so they can be compared in the development, staging and production repositories.

    Control eight: Validate artifact digest. Before an artifact is deployed in any environment, its digest should be validated against the artifact in the repository to ensure that it has not been compromised.

    Control nine: Pull requests require two reviewers (including one default reviewer) and a passing build to be merged. In addition to supporting good coding practices, this control also helps ensure that no commits are made without competent human oversight. 

    Control 10: Artifacts in higher repositories are signed. Requiring artifacts to be signed in a repository throughout the process ensures visibility and traceability for whatever is deployed to production. 

    Control 11: Available container images don’t have any high or critical vulnerabilities. Just as applications need to be tested for vulnerabilities before being placed in production, so do the container images into which they are packaged for deployment. Container images could have open source vulnerabilities if they contain open source software. 

    Control 12: Validate artifact signatures and digests. Validating the signature of the artifact against the digest ensures that the artifact was not tampered with in the repository and that the artifact being deployed is the same one that was tested.

    Control 13: Scan deployed images in production. This helps to ensure that the prior controls were followed for all software in production.

    Control 14: Validate Kubernetes resource manifests. If the resource manifests are tampered with, they could be tricked into deploying a container of the attacker’s choice. 

    Control 15: Ensure build environments are ephemeral and immutable. Build environments should be defined in code with automated creation and teardown and a fresh environment created for every build. Build hosts should not be accessible using interactive logins.

    We believe this blueprint provides engineering teams with an actionable architecture that security teams can rally behind and support. By adopting these standards, engineering teams are promised the delivery of assured software at lower risk of supply chain tampering, reduction of attacks during development and manipulation in staging and production.

    Here’s what it looks like:

    blueprint

    To learn more about the suggested blueprint, read our GitHub post about the project. Our goal is to prioritize speed and agility for software development while incorporating a security-always mindset.

  • Snyk Extends Tools Portfolio to Drive DevSecOps Adoption

    Snyk Extends Tools Portfolio to Drive DevSecOps Adoption

    During its online SnykCon 2021 conference this week, Snyk extended Snyk Code, a static application security testing (SAST) tool that already supports the Java, JavaScript and Python programming languages to include support for C#, Ruby, PHP and Go.

    At the same time, Snyk Open Source, a platform for remediating open source vulnerabilities, has been extended to provide native integration with Atlassian BitBucket and AWS CodePipeline platforms for driving DevOps workflows. Snyk has also tightened integrations with platforms from DigitalOcean and HashiCorp.

    Snyk also added support for the Elixir programming language and package managers Yarn 2 and Poetry alongside integration with a C++ scanning tool from FossilID, a provider of a software composition analysis (SCA) tool for open source code that Snyk acquired earlier this year.

    The Snyk Container platform is now integrated with the open source Trivy container scanning tools and with Snyk’s vulnerability database in addition to adding support for container registries such as Quay, GitHub Container Registry, GitLab, Google Artifact Registry and Harbor.

    The Snyk infrastructure-as-code platform now also makes it possible to detect configuration issues in Kubernetes manifests in Terraform code in a way that is compatible with cloud platforms from Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).

    Snyk also is adding support for version 3 of OpenAPI, which the company reports is three times faster than the previous version. That API is also the foundation for Snyk Apps that the company will continue to roll out.

    Finally, Snyk launched both a new free developer security education program, dubbed Snyk Learn, through which developers can attain and measure their level of DevSecOps expertise and Snyk Impact, an effort to foster collaboration among developers involving a wide range of socio-economic issues.

    Company president Guy Podjamy said as DevsecOps continues to evolve, the primary focus remains on developers and DevOps teams. However, as an issue, DevSecOps is also becoming more important at both the C-level within organizations as well as individual security operations teams. As such, and in the wake of recent high-profile security breaches, the sense of urgency surrounding DevSecOps is now a lot higher. The fundamental challenge organizations are trying to address is finding a way to improve overall application security without slowing down the pace at which applications are built, noted Podjamy.

    Snyk itself revealed it has secured an additional $530 million round of funding to address those issues. The company has now raised a total of $775 million to date with a valuation of $8.5 billion. Snyk also revealed it has increased annual recurring revenue (ARR) by 154% year-over-year from a customer base that now spans more than 1,200 organizations, including Asurion, Google, Intuit, MongoDB, New Relic, Revolut and Salesforce. Snyk customers and users collectively have run more than 300 million tests in the last 12 months to fix more than 30 million vulnerabilities in a 90-day period of time, the company claims.

    It may be a while before most organizations have embedded security tools within every DevOps workflow. However, given the resources being poured into DevSecOps, it may be more a question when DevSecOps will be finally achieved rather than if.

  • Tips for a Successful DevSecOps Life Cycle

    Tips for a Successful DevSecOps Life Cycle

    A DevOps implementation, if done correctly, can do wonders for any organization that’s on the hunt for efficiency, productivity and speed. As per the 2020 survey conducted by Atlassian, 99% of survey respondents said that DevOps has had a positive impact on their organization.

    However, it won’t do any good if security isn’t prioritized while adopting the DevOps best practices. That’s where DevSecOps comes into play.

    Enterprises need to understand that leveraging the alignment of development and operations for workflow enhancement while ignoring underlying security issues is like trying to generate electricity from a broken solar cell on a cloudy night. Undoubtedly, the success of any DevOps initiative predominantly relies on general security practices and a robust security mechanism to mitigate risks—this is where DevSecOps plays a vital role.

    There are several essential components of a successful DevSecOps implementation. Here’s how you can leverage them in your organization.

    The Emerging Need for DevSecOps

    DevOps can be simply defined as the next evolution of an agile development environment that bridges the gap between operations and development teams. Enterprises increasingly are turning to DevOps to boost their application development speeds and operational efficiency. Often, though, prioritizing development velocity means security concerns are left behind.

    That’s why there’s an equally growing need for a secure, efficient yet still agile development environment. DevSecOps puts security at the forefront of the entire operational and development process, which safeguards good cybersecurity hygiene right from the beginning. Implementing DevSecOps directly benefits developers and operations teams working hard to deliver a flawless application in a short period of time. Moreover, this approach encourages enterprises to develop secure code and thus, secure applications. To do so, there are several resources and strategies to help implement DevSecOps into an organization’s software development life cycle (SDLC).

    Secure Coding Practices

    Secure coding is perhaps the most crucial aspect of ensuring stringent security right from the beginning of the SDLC. Developers who aren’t following secure coding best practices, security guidelines and maintaining compliance while coding the application are inviting many security risks, including breaches of sensitive data and exploitation of an individual’s identity.

    Hence, an organization must focus on enhancing the skills of developers and ensuring that they are following security best practices while their application is in the initial stages of development. Moreover, establishing and adherence to coding standards are also crucial, as they help application developers to write clean code.

    Leveraging Automation

    As we know, automation is a driving force and a key aspect in DevOps; the same goes for DevSecOps. Automating security is vital to keep up with the pace of application code delivery, especially for more prominent organizations working on various code versions. Choosing the right automation testing tools can be beneficial for organizations that wish to speed up their operations and enhance the reliability of code when it comes to security. Organizations should strongly consider using at least static application security testing (SAST) tools that help developers identify potential vulnerabilities in code in the early stages of the development life cycle.

    Early Stage Testing

    The biggest mistake for any organization leveraging DevSecOps is testing the application only when it’s finally completed. Beginning early with automated testing offers numerous advantages, including identifying and resolving vulnerabilities in early development stages, a quick and inexpensive way to fix issues and saving valuable time during deployment.

    However, testing during the early stages of the SDLC may also halt the overall DevOps development pipeline, so take that into consideration from a security perspective.

    Implementing DevSecOps

    Implementing DevSecOps isn’t a quick process and requires specific steps to get it right.

    Planning and Development

    A solid planning strategy for successful implementation must include test criteria, design, vulnerability models and analysis. Once the planning is complete, the next step is development. Development teams should initially evaluate the overall complexity and challenges of their current practices. Adding a code review system in the development process can help to encourage safe and reliable coding practices in a DevSecOps environment.

    Build and Test

    Now it’s time to build! You can use automated tools to help combine source code with machine code; many of those build automation tools offer security features like automatic vulnerability detection. Once the build is complete, rigorous testing is carried out through various automated testing frameworks that ensure the highest level of performance and security.

    Monitoring

    Monitoring is another crucial aspect of DevSecOps implementation to ensure your security mechanisms are performing up to snuff.

    Undoubtedly, DevSecOps has revolutionized the way enterprises handle security, especially in challenging DevOps environments. Businesses that want to get to the next level of agility without sacrificing robust security should be implementing DevSecOps.

  • Secure Coding Adventure Park Virtual Summit: Wilder, Faster and More Visionary Than Ever

    Secure Coding Adventure Park Virtual Summit: Wilder, Faster and More Visionary Than Ever

    DevSecOps helps secure code from the start of production, rather than patching and debugging it at a later stage. It brings development, operations and security teams together so they can release secure software faster. At Secure Coding Adventure Park Virtual Summit, taking place on September 29, industry-leading AppSec and DevSecOps practitioners, analysts and visionaries will come together to share their wildest rides on the security roller coaster and discuss everything you need to know about build secure code from the ground up.

    The agenda for Secure Coding Adventure Park Virtual Summit features a mix of topics, including AppSec, DevSecOps, open-source security, CI/CD and more.

    Security luminaries from AWS, Secure Code Warrior, GitLab, Sysdig, WhiteSource and many other well-known IT companies, will discuss:

    • How to prevent supply chain attacks from code through production
    • Why developers struggle with application security
    • The role of AppSec testing in securing your software supply chain
    • How to protect your open source projects and create a secure CI/CD pipeline
    • How remote work has influenced DevSecOps adoption
    • How to best approach modern software security by automating your CI pipeline for simplicity, visibility and control

    This year’s Secure Coding features outstanding industry leaders, such as:

    • Harry Mower, general manager, AWS DevOps Tools at Amazon Web Services
    • Maciej Mensfeld, senior product manager at WhiteSource
    • Marina Segal, director of product management at Sysdig
    • Stefania Chaplin, EMEA’s solution architect at Secure Code Warrior
    • Cindy Blake, senior product marketing manager and security evangelist at GitLab
    • Rhys Arkins, director of product management at WhiteSource
    • Eric Tice, director global open source technical consulting and COE at Wipro
    • Jayne Groll, co-founder and CEO at DevOps Institute
    • Eilam Milner, co-founder and CTO at Argon Security
    • Jonathan Leitschuh, security software engineer at Gradle Inc.
    • Ricardo Sueiras, technical evangelist at AWS
    • Sonya Moisset, principal security engineer at Photobox, Epic Women in Cyber/Tech founder, GirlCode ambassador
    • Scott Gerlach, co-founder and CSO at StackHawk
    • Dave Walker, principal specialist solution architect for security and compliance at AWS

    Our very own Jackie Whetzel sat down with Stefania Chaplin for a quick interview about her upcoming session at Secure Coding Adventure Park Virtual Summit, women in tech and her journey as a solutions architect. Check out a clip of the interview below as Stefania shares a sneak peek of what to expect from her upcoming session.

    To check out the full agenda and to register, visit the Secure Coding Adventure Park Virtual Summit website.

  • Transform Mobile DevOps into Mobile DevSecOps

    Transform Mobile DevOps into Mobile DevSecOps

    Mobile developers are mostly focused on adding new features and functionality to their apps. Security features—such as RASP protection, obfuscation, encryption, jailbreak/root prevention and MiTM prevention—are usually addressed at the end of the development cycle if they are addressed at all. Unfortunately, most apps ship with significant vulnerabilities. One internal app test showed that most apps can be cracked within 15 minutes, and a recent academic study found that 67% of the malicious app installs came from the Google Play Store.

    An Appdome global survey of more than 10,000 smartphone consumers released in August 2021 showed that this approach—features over security—is an enormous mistake. Nearly two-thirds (63%) of consumers say they value security as much or more than features when it comes to mobile apps. Nearly three-fourths (73%) said that they would stop using a mobile app if it left them unprotected against attacks.

    The survey revealed a big shift in consumer sentiment. For the first time in recent history, consumers are on the security team’s side! They expect strong protection from threats and fraud. But meeting these expectations is extremely challenging for development teams, because DevOps and security are so often at odds. 

    Here’s why: Nearly all the work done in DevOps is automated, from GitHub to Jenkins to Fastlane, while almost all security work is manual. Sure, security software development kit (SDK) vendors position themselves as an alternative, but buyer beware. Implementing a security SDK is never just a couple of lines of code. It’s still a brittle, manual process that does not offer a guaranteed outcome.

    Mobile app security solutions available today don’t fit into the automated delivery model that is DevOps. The only way to automate security and make it fit within the DevOps workflow is to stop trying to squeeze it in at the end of the Dev cycle. As a result, security does not have a seat at the mobile app development table today. And as long as security is manual and cannot be seamlessly plugged into the existing DevOps workflows, it will remain an afterthought, at best.

    The Encryption Example: Why Security is so Hard

    As an illustration, let’s take a look at incorporating mobile encryption, an absolute necessity to protect data against harvesting, theft, interception, deception and trickery. For every type of data inside the app, developers must choose the right combination for each component of the encryption model, including encryption algorithm/protocols, cipher suites, key strength, key derivation technique, key protection and safeguarding. It has to match both the security and performance requirements for a highly variable set of data format characteristics. Even small errors or mismatches could slow app performance or render the app unusable. On the other hand, the app may perform well, but the encryption may be too weak to provide sufficient protection. 

    It’s complex, time-consuming work that developers don’t want to have to do twice. That’s why they tend to wait until after the app is built to add encryption. Unfortunately, this means all the network information is stored in the app unencrypted, and if a bad actor gets their hands on a UAT version of the app, the “keys to the kingdom” are in the clear, ripe for the picking.

    The demands on DevOps to get new releases out of the door quickly are high. Security is often seen as a negative force that holds back innovation and delays release, especially when it’s left until the very end of the software development life cycle (SDLC). The term DevSecOps is used to describe a security-focused, continuous delivery SDLC. But that should involve much more than penetration testing. Identifying issues isn’t enough. Security needs to be built into the development cycle without slowing down release times or creating uncontrollable costs.  

    The only way to incorporate security into DevOps and to achieve DevSecOps is to imbue security with as much automation as development currently enjoys. By using an automated, no-code platform that builds security directly into the app, security can become a natural part of the DevSecOps workflow. Plus, security can be consistently applied with documentation that demonstrates protection. It’s the only way to enable developers to get their secured mobile apps into the hands of their end-users at a rapid pace, align all stakeholders to a common shared set of objectives and outcomes and eliminate the sources of friction commonly found between DevOps and security teams. 

  • Zero-Trust Network Access Platforms Slash DevOps Bottlenecks

    Zero-Trust Network Access Platforms Slash DevOps Bottlenecks

    In a prior article, I indicated why a new remote zero-trust platform is needed to support DevOps teams.

    Traditional remote access configurations are not well-suited for DevOps given a shifting user population comprised of employees, contractors and other third parties often using their own devices; the large number of tools and systems to which access must be provided and the hybrid nature of the infrastructure itself (on-premises, hybrid and multi-cloud).

    DevOps Pain Points

    Three pain points are associated with traditional approaches when used with DevOps.

    1. DevOps user experience is poor in traditional remote access configurations. Each DevOps service must be accessed as separate secured sessions, which is confusing and tedious.
    2. System management requires IP whitelisting rules in VPN, static SSH keys in Bastion, firewall rules controlled by different teams and application-specific authentication. The coordination and execution of so many touchpoints for common actions—including the onboarding of new team members, changing roles or adding a new service—invites mistakes that cause productivity issues and introduces unforeseen security holes.
    3. Security is complex and error-prone. DevOps users must be granted restricted access to the individual services they need to be productive. Administering restricted access for individuals and groups is time-consuming. Security policies typically require monitoring detailed audit logs of user access.

    How a Zero-Trust Remote Access Platform Works with DevOps

    In my whitepaper, Zero-Trust-Remote Access-For-DevOps, I explain how a zero-trust remote access platform can resolve the requirements for improved DevOps user experience, consistent and manageable administration and simplified, less error-prone security.

    Improved DevOps User Experience

    By replacing the need for the user to tediously set up separate sessions for each DevOps service they need to use, a client-side DevOps service catalog enables all DevOps services to be accessed with a single click. This service catalog approach is more convenient for DevOps users and provides a form of DevOps governance. It does this by encouraging DevOps teams to select choices that are available in the catalog instead of creating new choices that result in expensive DevOps tool sprawl.

    Simplified DevOps Management

    Management of remote DevOps users is simplified by consolidating access for all DevOps users and services under a single unified service manager and connector. The need to manage each user and service with different teams, each with their own processes, is unified and streamlined when the management requirements for DevOps users and services are consolidated under a common zero-trust remote access platform.

    In addition, this approach makes it much easier to implement more adaptive policies across the breadth of users and services.

    With a zero-trust remote access platform, onboarding new DevOps users and groups is accomplished within a single session—not separate sessions for each onboarding requirement.

    Simplified and Less Error-Prone Security

    Consolidating access to DevOps services under a common zero-trust remote access platform with unified services and services connectors enables simplified and less error-prone security controls, improved security monitoring and policy management. Audit logs of access are reported consistently for all services. Monitoring and changing access rules can be supported for individuals or groups when adjusting a policy. Trust-based access controls can be implemented consistently. Granular policies ensure access is predicated on appropriate device trust score thresholds being met. Rather than a single check prior to granting access, these production services policies continuously assess the security of the users and devices accessing the services.

    Transforming to a Zero-Trust Remote Access platform for DevOps

    Transformations of all types, and especially those for DevOps, are made more certain by following a
    seven-step transformation process, described in my book Engineering DevOps. This process serves as a framework for implementing the zero-trust remote access platform.

    The first two steps, vision and team alignment, involve getting the leaders, key influencers and implementers of an organization to recognize and establish actionable goals for the implementation of the zero-trust remote access platform.

    The third step, assessment, requires taking inventory of the current state of DevOps users, DevOps services and policies that need to be supported by the new platform.

    The fourth step, road map, requires determining the plan for implementation. Typically, it makes sense to start with one application. Start with a set of DevOps users and DevOps services needed for a single application or pipeline which can serve as a model to drive adoption to other applications as the solution is proved and accepted.

    The fifth step, realize, is the step in which the zero-trust remote access platform is installed and set up for the initial model application or pipeline. Banyan Security explains how an example tool vendor helps to simplify this step.

    Capabilities to look in for in zero-trust remote access tools include:

    • Deploys in minutes, with no integration requirements on any existing DevOps services or infrastructure.
    • No need to set up VPNs, open inbound firewall ports or manage DNS.
    • Use existing DevOps user devices without diminishing security.
    • DevOps service catalog provides users visibility and one-click access to DevOps services.
    • Support for bundled services, favorites, and autorun capabilities.

    In step six, operationalize, the procedures for commissioning and using the zero-trust remote access platform are proven, benefits are measured and playbooks are hardened for the organization.

    In step seven, expansion, the zero-trust remote access platform deployment is expanded to other DevOps applications pipelines, DevOps users and DevOps services across the enterprise.

    What This Means

    Traditional remote access configurations are not well suited for DevOps administrators or users given the dynamic nature of services, team members, and environments. A zero-trust remote access platform addresses the need for an improved DevOps admin and user experience, simplified access management to DevOps services and simpler, less error-prone security practices and monitoring.

    I want to express my appreciation for the time spent with the Banyan Security team, who has pioneered many of the concepts outlined in this blog and contributed valuable insight.

  • Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype today released a report that finds there has been a 650% year-over-year increase in supply chain attacks aimed at upstream public repositories. Cybercriminals hope to compromise these repositories by injecting malware into software components that many organizations might be using, according to the report.

    The seventh annual State of the Software Supply Chain Report is based on an analysis of 100,000 applications and 4 million component migrations made in the last month alongside a survey of 702 software engineering professionals. Specifically, the report focuses on demand and security trends associated with the Java (Maven Central), JavaScript (npmjs), Python (PyPI) and .Net (nuget) ecosystems. The top four open source ecosystems now contain a combined 37,451,682 different versions of components, a nearly 20% increase year-over-year.

    Over the course of 2021, developers also downloaded more than 2.2 trillion open source packages from the top four ecosystems, a 73% increase over the prior year.

    However, despite the huge available supply of open source software, use of this software is primarily concentrated in a small number of popular projects. Production applications are only using 6% of available open source projects.

    Not surprisingly, popular projects are more vulnerable to compromise. A total of 29% of popular project versions contain at least one known security vulnerability. Conversely, only 6.5% of projects that are not widely used have vulnerabilities.

    Stephen Magill, vice president of product innovation for Sonatype, said popular open source projects tend to have better security practices in place because of the larger number of maintainers and contributors working on the project. The paradox is that less-popular open source software is not likely to be targeted by cybercriminals who tend to focus on targets that represent the best chance to infect downstream applications, said Magill. Popular open source projects were 2.8 times more likely to contain vulnerabilities, the report found.

    Projects with a faster mean-time-to-update (MTTU) are also generally more secure. They are 1.8 times less likely to have vulnerabilities, the survey found.

    The report also found developers make suboptimal choices 69% of the time when updating third-party dependencies, even when newer versions of projects are generally available. Developers may be avoiding those updates because they may be perceived to be not as stable as they would like. However, those updates generally contain the latest security patches needed to address a recently discovered vulnerability. Commercial engineering teams only manage 25% of the components they use, leaving the majority of their open source dependencies stale and susceptible to increased security risks, the report found.

    Finally, the report suggested there is a greater need for automation. Equipped with intelligent automation, a medium-sized enterprise with 20 application development teams would save a total of 160 developer days a year. Sonatype estimated that could save organizations $192,000 a year.

    In general, Magill noted that the security of software supply chains should continue to improve in the wake of an executive order issued by President Biden. In the meantime, however, most organizations would be well-advised to start reviewing the components and dependencies that make up their software supply chain sooner rather than later. After all, chances are good that cybercriminals are already doing much the same thing.