Tag: secure coding

  • Graylog Makes Free API Security Tool Available to Developers

    Graylog Makes Free API Security Tool Available to Developers

    Graylog this week made available a free version of its platform for securing application programming interfaces (APIs), intended to encourage developers to adopt best practices to secure them.

    The free version of Graylog API Security has all the capabilities of the paid version but is limited to 16GB of local rolling storage on a single node with a one-year renewable license.

    Graylog CEO Andy Grolnick said the goal is to make it simple for developers to use this edition of the platform as they are building APIs. As applications are deployed in a production environment, the expectation is organizations will then need to access the version of the platform that is designed to scale, he added.

    Based on technology Graylog gained with the acquisition of an API security platform originally developed by Resurface.io, this free version of Graylog’s API security platform is trying to help bridge the divide between the application development teams that create APIs and the cybersecurity teams tasked with protecting them, said Grolnick.

    Capabilities of the platform include API classification, discovery, risk scoring, an ability to capture API request and response payloads and continuous monitoring of API and threat signatures in real-time. Collectively, these capabilities enable Graylog API Security to provide high-fidelity alerts using a data lake that is embedded in the platform, noted Grolnick.

    That approach enables Graylog API Security to capture all API requests and response details to distinguish valid API traffic from malicious activity involving, for example, data exfiltration hiding under valid response codes.

    In addition, Graylog API Security automatically surfaces remediation guidance for developers who typically lack cybersecurity expertise.

    API security has become a major DevSecOps issue because cybercriminals are increasingly targeting APIs to steal data. As more externally facing APIs are deployed, the overall size of the attack surface that needs to be defended increases exponentially.

    A recent survey conducted by Enterprise Strategy Group (ESG) on behalf of Graylog found more than three-quarters of respondents (76%) have an average of 26 APIs per application. Most respondents are using open APIs for public consumption (67%) or are connecting applications with partners (64%).

    In general, most of those APIs are internally facing, but it’s not uncommon for those APIs to suddenly be exposed to the internet as use cases for applications evolve. The challenge is that few cybersecurity teams have visibility into APIs that, when manipulated by malicious actors, can expose code or provide a mechanism through which business processes can be compromised. This issue often exists because, in many organizations, it’s still not clear who is actually responsible for API security.

    Arguably, the best way to ensure API security is at the point of creation. Providing developers with API security tools gives them a chance to do the right thing from the beginning of the application development process, said Grolnick.

    There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it.

  • Snyk Survey: AI Generating More Vulnerabilities in Code

    Snyk Survey: AI Generating More Vulnerabilities in Code

    A survey of 404 IT professionals conducted by Snyk found the use of artificial intelligence (AI) to write code is creating a security paradox. On one hand, just over three-quarters of respondents (77%) said AI tools improve code security. At the same time, however, 59% are concerned that AI tools trained using general-purpose large language models (LLMs) will introduce security vulnerabilities that first appeared in the code used to train them.

    The challenge with general-purpose LLMs is that they are trained using a combination of excellent, mediocre and flawed code. As a result, any recommendation surfaced has the potential to be a suboptimal security result.

    Randall Degges, head of developer relations for Snyk, said that as AI tools increase the velocity at which applications can be constructed, it’s probable that DevOps teams will discover more vulnerabilities in their code.

    In general, 61% of respondents also noted that automation has increased the number of false positives, with 62% of respondents reporting that at least one out of every four vulnerability alerts they received from automation tools were false positives. Well over a third (35%) said false positives represented over half of the vulnerability alerts.

    On the plus side, however, more organizations are paying closer attention to application security issues in the wake of several high-profile breaches of software supply chains and disclosures of vulnerabilities. A full 96% reported their organizations are addressing supply chain security problems on an ad hoc basis, yet only half have a formalized supply chain security strategy in place.

    The survey also finds 87% of respondents work for organizations impacted by a software supply chain security issue in the last year, with 61% having implemented new tools and processes as a result.

    A total of 62% of respondents work for organizations that have a software life cycle assurance process in place, but only 42% of organizations are using software bills of materials (SBOMs). In addition, only 40% have formal security ratings for the open source packages that developers employ, and 31% ignore risks that arise from indirect dependencies.

    However, only 40% of organizations have embedded security testing tools into their integrated development environments (IDEs), with 40% not using software composition analysis (SCA) or static application security testing (SAST) tools at all. In fact, even though 80% of respondents reported working for organizations that ship code daily, only 27% claim to continuously audit their code.

    As a result, many vulnerabilities remain unpatched, with Java (42%) and JavaScript (31%) topping the list in terms of code with the most ignored vulnerabilities.

    Finally, the survey also noted that vulnerabilities involving open source code are now being remediated faster than proprietary code. Maintainers of open source software are now paying more attention to cybersecurity issues thanks in part to the tools and best practices provided by the Open Source Security Foundation (OpenSSF), said Degges.

    There will, of course, come a day when AI is more widely used to analyze vulnerabilities in code. In effect, AI will be used to solve some of the security issues general-purpose LLMs create. In the meantime, however, DevSecOps teams would be well-advised to proceed with caution.

  • DevOps Security: Your Complete Checklist

    DevOps Security: Your Complete Checklist

    In a fast-paced environment like DevOps, your security strategy needs to be even more agile. While moving fast is great for delivering application features and functionality, speed shouldn’t come at the cost of security.

    DevOps security incorporates security strategies directly into your DevOps pipeline, creating a culture of pre-secured software deployments that work seamlessly for the end user. However, this requires a complete shift in your operational policies and security mindset. You need to start viewing security as an integral part of your DevOps lifecycle instead of a separate department.

    Here’s a checklist of DevOps security strategies for your development teams to deliver secure and reliable applications faster:

    Your Complete DevOps Security Checklist

    1. Analyze your development process for security hazards.
    The first step in implementing a DevOps security strategy is finding and fixing loopholes in your existing development process.

    For instance, continuous delivery and development are key in a DevOps environment. However, if each change doesn’t go through a code review, it has the potential to break your application.

    Deploying changes without passing them through a security checkpoint is like driving at high speed on a road with many curves. Each curve (change) is a potential hazard, and the danger increases when the driver does not know a car is coming from the other side (bug).

    Therefore, you must turn the spotlight on your development process and find those curves.

    2. Create a common goal between development and security teams.
    Traditional roles of developers and security teams might look like they are at crossroads — Developers write code, and security teams find fault with their code. However, in a collaborative environment such as DevOps, security and development must work hand-in-hand to deliver a secure and seamless experience to end users.

    Your organization should have a common goal of integrating security directly into the development process. Therefore, encourage open and regular communication between development and security teams. Further, establish joint milestones and review them to ensure there are no silos between both teams.

    Once these teams get used to this collaborative approach, your deployments will become faster because fewer things will break.

    3. Integrate security procedures in the development phase.
    Automation is the lifeblood of DevOps security. Integrating scanning tools into development workflows is critical to your entire process.

    For example, automated tools can scan the code, network and infrastructure to identify security vulnerabilities and provide recommendations for remediation. With this, development teams can fix a few security concerns themselves before passing them on to the security team for a final check.

    4. Add observability to your pipeline.
    One of the biggest challenges of the distributed nature of DevOps operations is visibility. How do you efficiently monitor a large number of operation nodes spread across several different locations?

    Observability helps you do this by using logs, metrics and traces—i.e., the outputs of your application to determine internal application health. With observability tools, you can see much deeper into the operations of your systems and identify the exact details of any security concerns. You can also easily identify potential bugs and fix them before they cause problems.

    5. Make changes in small, incremental units.
    It is infinitely easier to test code in small units and deploy them as minor but incremental changes than handling large, unwieldy blocks of monolithic code. Deploying gradual changes means you can resolve vulnerabilities faster.

    6. Scan and secure your entire DevOps pipeline.
    A large part of the security hazards in your DevOps process comes from unsecured containers and operations nodes. According to a study from ThreatStack, 94% of organizations say containers represent a security risk.

    However, the risk is not limited to containers.

    Other services like APIs, third-party tools like Docker and imported code pose a potential security risk to your processes. This makes it necessary to scan all your operations nodes periodically for vulnerabilities. And once you’ve cleared them, remember to lock the door behind you by requiring strict credentials for access to your administrative dashboards.

    Ticking Items Off Your DevOps Security Checklist

    If you implement most of the security guidelines on this checklist, your organization will have a solid security foundation. However, DevOps security is not a one-time process.

    You will need to continuously integrate security protocols into each part of your DevOps life cycle. Furthermore, you will need to re-train your employees and invest in new technology that makes your security pipeline smoother, such as observability.

    However, since this entire process makes your applications more secure and compliant while shipping them to market faster, investing in DevOps security is well worth it!

  • GitGuardian Survey Surfaces Secrets Management Challenges

    GitGuardian Survey Surfaces Secrets Management Challenges

    A survey of 507 IT decision-makers in the U.S. and the United Kingdom published today found 75% of respondents said a secret leaked from at least one application, with 60% noting that the leak caused issues for either the company, employees or both.

    Conducted by Sapio Research on behalf of GitGuardian, a provider of a platform for securing application secrets, the survey found less than half of respondents (48%) are confident in their ability to protect application secrets to a great extent.

    The top source of risks when it comes to secrets management are source code and repositories (58%), followed by hard-coded secrets (47%). Just under a third (30%) of respondents to the GitGuardian survey admitted they share passwords and secrets when building applications as clear text within a messaging application.

    Just over a quarter (27%) still relied on manual code reviews to prevent secrets leaks, the GitGuardian survey found.

    On the plus side, 94% of the respondents said they were considering improving their secrets management practices in the coming 12-18 months, even though 93% said either “all” or “some” of their repositories were continuously scanned for hard-coded secrets.

    Thomas Segura, a cybersecurity expert for GitGuardian, said as the number of applications developed continues to increase, secrets sprawl has become a bigger challenge for application security. The way secrets are managed during application development has become a bigger issue in the wake of a series of software supply chain breaches that led to malware being injected into applications.

    The concern is cybercriminals that compromise software development environments will be able to retrieve secrets that they can later use to compromise an application after it has been deployed in a production environment. Cybercriminals are also now routinely scanning for secrets that may have been stored in text after an application has been deployed.

    The challenge is that secrets have not been historically managed effectively, so many organizations are now looking to implement more rigorous processes. Another challenge is that, in many cases, it’s not apparent whether those processes will be implemented by a DevOps team familiar with how an application is constructed or an application security team with more cybersecurity expertise, noted Segura.

    Regardless of the approach to remediating these issues, there is always going to be an issue because the humans who build applications are always going to make mistakes. The goal is to minimize the number of secrets that might be leaked by implementing DevSecOps practices that automate the review process, said Segura.

    In theory, at least, advances in artificial intelligence (AI) should make it easier to automate more of the secrets review process. In the meantime, however, organizations need to review their existing processes in advance of pending legislation that looks to hold organizations more accountable for application security if it is determined that the organization did not take reasonable precautions.

    It may be a while before such legislation becomes law, but one way or another, it’s clear that DevOps teams are soon going to be asked tougher questions about how secrets were managed every time an application security breach occurs.

  • Codenotary Previews Secure SBOM Creation Service

    Codenotary Previews Secure SBOM Creation Service

    Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

    Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

    Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

    Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

    In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

    Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

    It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

    On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.

  • 5 Unusual Ways to Improve Code Quality

    5 Unusual Ways to Improve Code Quality

    Code quality refers to how well-written and maintainable software code is. It encompasses factors such as readability, efficiency, scalability, reliability, maintainability and security. High code quality ensures that software is easy to understand, modify and extend, has fewer bugs and is less likely to break down. It also reduces development time and costs and improves the overall user experience. One common approach to determine code quality is to use automated tools that analyze the code based on predefined quality standards and generate a report with a numerical score.

    Why is Code Quality Important?

    Generating high-quality code ultimately enhances the end user’s experience. Focusing on creating quality code can also help consumers understand the safety and reliability of the software or program they’re using.

    Low-quality code can affect user experience and satisfaction, making it critical to write high-quality code that functions properly. When developers write low-quality code, it can create vulnerabilities that expose the software to cybersecurity threats, resulting in bugs and functionality issues and impacting the software’s reliability. 

    Here are some additional reasons high-quality code is important: 

    • Enhances code readability: Readability is important because it leads to higher rates of understanding among other developers. A code that’s easy to read is also easy to improve.
    • Improves the level of program sustainability: Program sustainability measures how long a code can survive with minimal changes. High-quality code can last for years, making it more sustainable.
    • Increases transferability: Transferring code from one platform to another is a complicated process. It’s much easier for developers to transfer high-quality code, as they only need to make minimal changes.
    • Lowers costs related to program or software: When software lasts for a long time with few errors, it can save a company money. Instead of paying for additional time to rewrite low-quality code, the company can rely on the original, high-quality source code.

    5 Unusual Ways to Improve Code Quality

    Here are a few ways you may not have thought of which can help your development team improve code quality and end-user satisfaction.

    Bug Bounty

    A bug bounty program is a type of crowdsourced security testing in which an organization offers rewards to independent security researchers or ethical hackers for identifying and reporting vulnerabilities in their software or systems. By offering rewards for vulnerabilities, organizations can incentivize security researchers to find and report security issues before they can be exploited by attackers.

    Bug bounty programs can improve code quality in several ways:

    • Incentivize security testing: Bug bounty programs incentivize security researchers to test an organization’s software or systems for vulnerabilities. This can increase the amount and quality of security testing that is done, leading to a more secure product.
    • Encourage responsible disclosure: Bug bounty programs encourage security researchers to report vulnerabilities directly to the organization rather than publishing them publicly or selling them on the black market. This allows organizations to fix vulnerabilities before they are exploited by attackers.
    • Provide feedback on code quality: Security researchers who participate in bug bounty programs can provide feedback on code quality which can help organizations to improve their development practices and write more secure code in the future.

    Auto-Generated Documentation

    Auto-generated documentation is a type of documentation that is generated from code comments and metadata as part of an automated development pipeline. It is typically generated using tools such as Javadoc, Doxygen, or Sphinx, which parse code comments and metadata to generate HTML, PDF, or other formats of documentation.

    Auto-generated documentation can improve code quality in several ways:

    • Improved code readability: Auto-generated documentation can provide clear and concise descriptions of code functionality, making it easier for developers to understand the code and its purpose.
    • Better code organization: Auto-generated documentation can help developers organize their code by providing a clear hierarchy of classes, methods, and functions, making it easier to navigate and maintain the codebase.
    • Consistency: Auto-generated documentation can ensure that documentation is consistent across the codebase, reducing the risk of errors and misunderstandings.
    • Quality assurance: Auto-generated documentation can be used as a quality assurance tool, helping developers to identify errors and omissions in their code comments and metadata.

    Coding Conventions

    Coding conventions are a set of guidelines and standards that outline how code should be written and formatted to promote consistency and readability. They typically cover aspects such as naming conventions, code structure, formatting, and documentation. 

    By following coding conventions, developers can improve code quality and make their code easier to read and understand, which makes it easier to maintain and modify. They also help ensure that code is consistent across a project or organization, which can make collaboration and integration of different code segments easier.

    Typical elements that coding conventions dictate include:

    • Naming conventions for variables, functions, and classes.
    • Indentation and formatting of code blocks.
    • Use of whitespace and comments to improve readability.
    • Guidelines for handling exceptions, errors, and input/output.

    Quality Gates

    Quality gates are a set of checkpoints or criteria that software must meet before it can progress to the next stage of development. They are typically used in software development processes to ensure that the software is of a certain quality and is ready for release.

    Quality gates can be automated or manual, and they are typically implemented at key points in the development process, such as after unit testing, integration testing, or acceptance testing. They can include metrics such as code coverage, code quality, functionality, performance and security.

    By enforcing quality gates, development teams can catch and address issues earlier in the development process, which can reduce rework, save time and ensure that the final software product meets the required quality standards.

    Smart Code Snippets

    Smart code snippets, also known as intelligent code snippets or live templates, are pre-written code fragments that can be inserted into a code file with placeholders for variables or user-defined inputs. They are designed to help developers write code more efficiently and accurately by reducing the amount of repetitive or boilerplate code they need to write and by providing contextual awareness and intelligence.

    Regular code snippets are static pieces of code that can be inserted into a file as needed. They typically contain pre-written code blocks or templates that can be customized to fit the specific use case.

    In contrast, smart code snippets are dynamic and can adapt to the context of the code being written. For example, a smart code snippet might include placeholders for variables that need to be defined or automatically fill in common code constructs based on the context of the code. 

    Conclusion

    The five lesser-known ways to improve code quality discussed in this article offer a starting point for teams looking to take a fresh perspective on their development process. Improving code quality is critical for the success of any software development project. While there are many established methods and best practices for improving code quality, there are also some less conventional approaches that can be surprisingly effective. By adopting a creative and open-minded approach to software development, teams can identify new ways to improve code quality and build more reliable, efficient and secure software.

    Image Source 

  • Will DevSecOps Replace the Security Operations Center?

    Will DevSecOps Replace the Security Operations Center?

    Traditionally, a security operations center (SOC) is a physical facility where an organization performs information security activities. The SOC team analyzes and monitors the organization’s security systems. A SOC aims to protect businesses from security breaches by identifying, analyzing and responding to cybersecurity threats. 

    The SOC team consists of administrators, security analysts and security engineers. They work in collaboration with internal development and IT operations teams.

    A SOC is a proven method to improve threat detection and incident response, reduce the potential for security breaches and help organizations respond appropriately in the event of an incident. The SOC team isolates unusual activity on servers, databases, networks, endpoints and applications, identifies and investigates security threats and responds to security incidents as they occur.

    SOCs were once considered suitable only for very large organizations. But many small organizations today are building lightweight SOCs, such as hybrid SOCs that rely on a combination of part-time in-house staff and outsourced experts or virtual SOCs that function without physical facilities.

    SOC Challenges

    SOCs play a critical role in protecting an organization’s assets from cyber threats and ensuring the security and integrity of its networks and systems. However, SOCs can face a variety of challenges in their efforts to detect and respond to potential threats, including:

    Alert Overload

    Alert overload is a common challenge faced by SOCs. It occurs when the SOC team is inundated with too many security alerts, making it difficult to prioritize and effectively respond to them. This can be caused by a high volume of alerts, a lack of context or proper prioritization, limited visibility, or limited resources. To address the challenge of alert overload, SOC teams may implement strategies such as tuning security tools, implementing a triage process, utilizing automation, and increasing the size of the team.

    Visibility Gaps

    Visibility gaps refer to areas of an organization’s networks and systems that are not adequately monitored or protected by security tools and processes. These gaps create vulnerabilities that cyber threats can exploit, making it difficult for SOC teams to detect and respond to potential threats. 

    Visibility gaps may be caused by complex environments, limited resources, shadow IT, or misconfigured systems. To address visibility gaps, SOC teams may implement strategies such as implementing a security information and event management (SIEM) system, conducting regular assessments, implementing additional security controls, educating employees and ensuring that systems are properly configured.

    Complex Investigations

    Investigating cybersecurity threats can be a challenging task for SOC teams. It requires them to quickly and accurately identify the root cause of the threat and take appropriate action to contain and mitigate it. This can be difficult due to limited visibility, complex environments, a lack of context or limited resources. 

    To aid in the investigation process, SOC teams may use forensics tools to gather and analyze evidence related to potential security incidents. Common tools include network forensics tools, which allow the team to analyze network traffic and identify the source of a threat and digital forensics tools, which allow the team to examine devices and systems to identify evidence of an incident. 

    Slow Detection and Response Times

    Slow detection and response times are a common challenge faced by security operations centers (SOCs). They can impact the organization’s mean-time-to-detection (MTTD) and mean-time-to-response (MTTR), which measure how long it takes the SOC team to detect and respond to potential security incidents. 

    A high MTTD and MTTR can have serious consequences for an organization, as it may allow a cybersecurity threat to remain active for an extended period of time, potentially causing significant damage.

    What Is DevSecOps?

    DevSecOps stands for development, security and operations. It is a new work process that involves integrating security practices into all DevOps processes. The DevSecOps mindset guides all technical experts equal access to security expertise.

    DevSecOps moves security practices and enforcement early in the development process. This creates a culture where security is everyone’s responsibility, not just that of the security team.

    Building security into every phase of the software delivery life cycle enables continuous integration and high development velocity with fewer security issues and lower compliance costs.

    How DevSecOps Improves Security and Quality

    Organizations using the DevSecOps model understand that security should not be an afterthought and should be a core part of the software development life cycle (SDLC).

    DevSecOps collaboration is more difficult than DevOps because it requires achieving two seemingly contradictory goals simultaneously—expediting the delivery process while spending more time to make sure code is secure and free of bugs.

    To implement DevSecOps without compromising product quality, organizations need to create a culture that deals with security-as-code, encouraging developers to consider the security aspects of their projects and automate security tasks. Organizations need to establish ongoing communication and collaboration between IT engineers, software developers and security teams.

    How DevSecOps Processes Are Transforming the SOC

    Traditionally, SOC processes were completely isolated from the rest of the organization. Developers would build systems, IT Ops run systems, and security protected them. Today, it is understood that merging these three functions into one organization that shares responsibility for security improves security and significantly increases operational efficiency.

    SecOps was a second phase, in which operations and security teams became one organization. Security was shifted left, starting from early stages of IT requirements and system design, not at the end of the process.

    SecOps had a major impact on organizations implementing DevOps. It paved the way for the third phase—broader collaboration between security, operations, and software development teams, known as DevSecOps. This moves security even further to the left, building security into the system from the first iteration of development.

    DevSecOps can operate in parallel to a SOC. Here are some ways SOCs can modernize their processes, even if the SOC itself is a silo:

    • Develop a decentralized SOC with DevOps members: Department members familiar with DevOps can help with incident response by gaining insight into IT systems and understanding vulnerabilities and threats to security personnel.
    • Collaborate with threat hunters and DevOps teams: Instead of isolating threats and reporting them to management, threat hunters can communicate directly with development or operations teams to address key security vulnerabilities.
    • Create a Center of Excellence: SOCs can work with development and operations teams to adopt security best practices and spread these positive results throughout the organization to promote DevSecOps practices.
    • Allow the SOC to provide advice and guidance: Everyone involved in security should have easy access to the SOC and be able to work with the organization’s top security experts.

    Conclusion

    In conclusion, while DevSecOps can significantly impact how SOCs operate, it is unlikely to completely replace the SOC. DevSecOps emphasizes the integration of security practices and tools into the development process from the beginning, which can help to prevent security incidents from occurring in the first place. However, it is still important for organizations to have a dedicated team in place to monitor for and respond to potential security incidents.

    The SOC will continue to play a critical role in protecting an organization’s assets from cybersecurity threats and ensuring the security and integrity of its networks and systems. By adopting DevSecOps practices, the SOC can improve the security and quality of the organization’s software applications, reduce the risk of security incidents and improve the efficiency of its operations. However, the SOC will remain a vital part of the organization’s overall security posture and will continue to evolve and adapt to new challenges as they arise.

  • What Developers Need for Software Security Success

    What Developers Need for Software Security Success

    Given today’s evolving threat landscape, organizations and businesses in every sector now have a critical need to produce secure software. Criminal gangs, professional attackers and hostile nation-states are employing advanced tactics designed to exploit any vulnerabilities in programs, applications, networks and even raw code. Attackers are constantly finding new ways to bypass even the most advanced protections and defenses. For example, many have shifted their focus from delivering malware to instead compromising credentials, or launching targeted attacks against a supply chain. And while those high-level incursions are happening with much greater frequency, so too are the more basic attacks like ransomware and SQL injections that have been a scourge on cybersecurity defenses for many years. It’s becoming apparent that while cybersecurity platforms and defenses are critical components in defense against modern attacks, what is truly needed is secure code that can be deployed free from vulnerabilities. And that requires security-aware developers with verified security skills.

    Most developers say they are willing to champion security and commit to higher standards of code quality and secure output, but they can’t do it without a lot of support, as well as a reworking of the traditional metrics by which they are often judged by their employers and organizations.

    Why Most Developers Don’t Prioritize Security

    Coding best practices have continued to evolve over the years in response to business needs and market trends. In the past, most applications were created using the so-called waterfall development model where software engineers worked to get their code ready to meet an ongoing series of milestones or goals before moving on to the next phase of development. Waterfall tended to support the development of programs that, having met all of the previous milestones along the way, were free from bugs or operational flaws by the time they were ready for the production environment. But it was slow going, with sometimes 18 months or more between starting a project and getting to the finish line.

    The Agile method tended to replace Waterfall, putting a much greater emphasis on speed. And this was followed by DevOps, which is built for even more speed by combining development and operations together to ensure that programs are ready for production almost as soon as they clear the final development tweaks.

    Putting speed over security—and nearly everything else beyond functionality—was a necessity as the business environment evolved. In a cloud-based world where everyone is online all the time and mobile transactions by the millions can happen every few seconds, getting software deployed and into the continuous integration and continuous delivery (CI/CD) pipeline as quickly as possible is critical for business success.

    It’s not that organizations didn’t care about security. It’s just that in the competitive business environment that exists in most industries, speed was seen as more important. And developers who could match that speed thrived to the point where it became the primary means by which their job performance was judged.

    Now that advanced attacks are ramping up so dramatically, deploying vulnerable code is becoming a liability. The preference is once again shifting, with security increasingly becoming the primary focus of software development, with speed a close second. Bolting on security after the fact is not only dangerous, it also slows the process of deploying software. That has led to the rise of programs like DevSecOps that attempt to merge speed and security together to help generate secure code. But developers trained for pure speed can’t become security experts without a lot of help and support from their organizations.

    What Developers Need

    The good news is that most developers want to see a shift to secure coding and a reprioritizing of security as part of the development process. In a comprehensive survey conducted by Evans Data of over 1,200 professional developers actively working around the world earlier this year, the overwhelming majority said they were supportive of the concept of creating secure code. Most also expected it to become a priority in their organizations. However, only 8% of the respondents said that writing secure code was easy to accomplish. That leaves a lot of room for improvement within most organizations’ development teams between what is needed, and what is required in order to get there.

    Simply mandating secure code won’t get the job done. Development teams need training, support and a change in how software engineers are valued and judged within their organizations.

    The biggest thing that is needed is more and better training for them. And it should be customized so that less experienced developers can begin their training by learning how to recognize the kinds of common vulnerabilities that often creep into code, with lots of hands-on learning and examples. Meanwhile, more advanced developers who demonstrate their security skills can instead be tasked with things like advanced threat modeling concepts.

    Teamwork should also be emphasized so that the developer community can help one another grow their skills. Skilled and willing developers who know security should be appointed as security champions. Their responsibility as a champion will be to help fellow developers improve their skills. And while a security champion is almost always an informal title, they should be given the respect, rewards, and compensation that such an important position deserves.

    In addition to funding and supporting training programs and security champions, including giving developers enough time away from coding in order to properly participate in those programs, organizations also need to change the way that developers are evaluated. The primary metric for rewarding developers needs to shift away from raw speed. Instead, evaluations could reward those developers who can create secure code that is free from vulnerabilities or exploits. Yes, speed can be an evaluated factor as well, but first and foremost, code needs to be secure and free from vulnerabilities.

    Producing insecure or vulnerable code is no longer an acceptable risk for most businesses. And bolting on security after the fact is becoming increasingly ineffective. Thankfully, the best weapon to fight this disturbing trend is having the developer community produce secure code that attackers can’t exploit. Most developers are willing to step up to that challenge. They just need the proper training and support to help make it happen.

  • Avoiding Security Review Delays

    Avoiding Security Review Delays

    In the summer of 2021, I had lunch with a senior security developer at one of Seattle’s leading tech firms. Even though we were relaxed in the sunny and cool afternoon of the Pacific Northwest, there was no doubt my friend was frustrated. Part of his job was running code through a popular scanning product and then evaluating the results. It was a tough role because he sat outside the team that was developing the code and he was often under pressure to run his analysis within the constraints of their deadlines. 

    All too often, he had to deliver the bad news that the scan had found security issues. But that alone wasn’t why he was frustrated. His issue was that the tool that he was using was taking several hours to complete scans. He’d taken to starting the scan at the end of the week and hoping that it would be complete by Monday morning. The very tool that was supposed to make his job easier was actually a headache.

    This is one of the fundamental challenges of analyzing software systems for security vulnerabilities. All too often, developers and stakeholders focus their project timelines on the functional specifications. Teams work feverishly to rapidly iterate from prototype to finished product. 

    Security concerns are never disregarded, but the culture of “Let’s see if we can get it working the way we want first and button it up later” ends up costing more in the long run because the evaluating and testing cycles take longer. Not to mention that if substantial security problems are found, it can be difficult to remediate them without breaking things that were supposed to already have been completed. This problem is becoming acute in the SaaS world where solutions are being built faster than ever before with little to no security oversight.

    The Right Tools and Software Are Critical

    First, managers and executives need to mandate that the entire software development lifecycle and every environment should have security. Particularly for web-based SaaS tools, any vulnerability that exists is a potential attack vector. Attackers know that going after a dev version might not yield a jackpot, but it might give them access that exposes credentials that work in later versions or identifies a vulnerability that flies under the radar into production.

    Second, automation and tooling are simply the name of the game. Using tools with code repositories, pipeline management and testing frameworks help ensure the elimination of as many potential vectors of error as possible. Security checks should be the same. We can’t always rely on the skills of a developer or an administrator to follow security best practices. 

    We need tools that provide reliable and rigorous checks. Moreover, these tools need to run frequently. SAST scanning should be fast enough that a developer can run it with every save, or at least every commit. Coupling SAST and IAST scanning together is the gold standard for secure development. Every time code is compiled into a dev or test environment, it should be tested to make sure that vulnerabilities haven’t crept in and that the permissions and architecture of the system don’t work at cross purposes to expose vulnerabilities.

    Finally, there is a fundamental issue that must be addressed in every manager’s office. Code quality is not the same as security. Sure, there might be some overlap, but it doesn’t make sense to have 200 rules for code quality and 50 for security. The two things are not equal, and it’s a fallacy to expect that having high-quality code without frequent security checks will ultimately lead to less time spent in security review. Don’t miss the forest for the trees. Make sure security is the team’s top priority.

    Advocating for Security in SaaS

    My friend didn’t have a problem holding teams accountable for the code they’d written. In fact, he relished being able to insist on high standards and was proud that his organization empowered him to do so. That’s exactly what we need in the software industry: Individuals who are unafraid to demand the best from their peers. But it’s imperative that we provide effective tools they can rely on to succeed.

    The problem of security testing delays are not new to software development. It has been well-documented that it can take 640x the money to fix bugs in production, but due to a lack of effective tools this problem has been amplified in SaaS development. A SaaS development environment presents unique challenges that cannot be met by just employing code analysis or configuration testing for SSPM vendors. It requires a holistic view of the environment and the ability to use customization to be effective in the identification and remediation of vulnerabilities. 

    With a comprehensive view, those responsible for security and those implementing it will see security as a necessity to innovate quickly rather than a necessary evil that is put off until last in hopes it can be avoided. Maybe then my friend won’t be as frustrated next time we meet.