Why Purchase Through AWS Marketplace?

In case you’re unfamiliar, AWS Marketplace is a curated, digital catalogue that helps customers around the globe find, buy, and use third-party software and services that run on AWS.
To purchase Checkmarx products via the Marketplace Private Offer, organizations can engage with a Checkmarx salesperson and receive product and pricing information not publicly visible on the Public Offer Marketplace. To purchase, all we need is the organization’s AWS Account Number to create a personalized quote. From there, acceptance, purchase, and deployment are just a few clicks away!
CxCodebashing, our developer application security training solution can be purchased both via Marketplace Private Offer and our public listing.

The benefits of purchasing Checkmarx solutions through AWS Marketplace include:

• Simplified billing: Transacting over AWS Marketplace accelerates the closing and procurement processes. All billing is handled directly on customers’ AWS invoices as a line item, helping to avoid procurement steps that typically accompany purchasing software from a new vendor.
• Retire EDP commitments: AWS’s Enterprise Discount Program (EDP) is AWS’ way to provide enterprises a discount based on a volume (consumption) purchase commitment. A simple example of how an AWS EDP might work is as follows: for the next three years, the customer would commit to spending $5MM on AWS services, and in exchange, receive a 13% discount. Even if the customer doesn’t spend $5MM, they would still owe AWS $5MM. For customers participating in the EDP program, purchasing Checkmarx over AWS Marketplace is an attractive proposition. For every dollar spent on Checkmarx, 50% of the purchase can be applied to their AWS spending obligations.

• Purchase in a time of limited budgets: Reduced budgets amidst current economic uncertainties can make it challenging to purchase solutions that address the ever-present cybersecurity and application security threat landscape. The ability to purchase Checkmarx using pre-allocated AWS budgets provides security departments the ability to acquire our best-in-class software security solutions that might otherwise have been stalled due to temporary budget constraints.

• Custom terms & pricing: Checkmarx can support custom terms, where applicable, and offers flexible options like multi-year contracts.

Why AWS Customers Should Consider Checkmarx

Checkmarx enables organizations to easily automate application security testing as part of their cloud-based software development process so they can improve the security and quality of their software without slowing down development, delivery, and deployment timelines. Checkmarx integrates with leading source code management tools like GitHub and GitLab to enable seamless code scanning within developers’ typical workflows.
Key features and benefits enjoyed by both developers and security teams include:

• Ability to scan raw source code before a build takes place, enabling greater efficiency between developers and AppSec teams;
• Prioritized SAST and SCA scan results to focus and expedite developer remediation efforts on vulnerabilities that pose the greatest threat;
• Automated results feedback loop to eliminate the need for manual intervention when opening and closing defects;
• Direct links into the Checkmarx Software Security Platform and access to its dedicated service and support resources for even more comprehensive results and coverage; and
• Links to just-in-time, lesson-specific training via Checkmarx Codebashing and online resources for remediation guidance to elevate developers’ secure coding skills.

What else sets us apart as an AWS partner?

Robust DevOps Integrations:
Checkmarx provides integrated support for AWS CodeStar services, allowing customers to initiate Checkmarx application security testing scans from AWS CodeBuild and AWS CodePipeline for code that is stored in CodeCommit. Additionally, we have integrations with the industry’s top source control repositories, CI/CD pipelines, defect tracking, and feedback channels. With our CLI & REST APIs, we can integrate into virtually any other tool with ease.

Trusted and Backed by AWS:
Checkmarx is an AWS Advanced Program Network (APN) partner, AWS’ highest-tier technology partner. Additionally, Checkmarx is the first and only AppSec solutions vendor to possess both the AWS Security Competency and DevOps Competency status. The competency process involves AWS vetting, validating, and verifying Checkmarx’s deep industry experience, expertise, and track record of customer success and delivering specialized software.

Industry Leader Amongst Analysts and Customers:
Checkmarx has been named a “Leader” in the Gartner Magic Quadrant for Application Security Testing for three consecutive years, a testament to the quality of our solutions and value they bring to customers. We have also been recognized with the Gartner Peer Insights Customers’ Choice for Application Security Testing for two years running due to our overall product capabilities, seamless integration into DevOps, and expert customer service.
Checkmarx is proud to work with over 1,400 customers across the globe – ranging from Salesforce to Samsung – helping to improve the security and quality of the software they build. Just take it from one of our valued customers:
“If your company’s developer workforce is not used to incorporating security standards into their builds, the Checkmarx stack of tools will do wonders for you in terms of integrating into your existing pipelines and providing the education via Codebashing that your developers will need.” Application System Analyst, Finance Industry [read full review]

Ready to Get Started?

If you’re an AWS customer interested in purchasing Checkmarx’s AST solutions via AWS Marketplace, or want more information and assistance, please visit here.

1. Develop and implement a plan for ongoing security and privacy assessments;
2. Perform testing/evaluation;
3. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;
4. Implement a verifiable flaw remediation process;
5. Correct flaws identified during testing and evaluation.

Control SA-11, which is quite comprehensive, also calls out:

1. STATIC CODE ANALYSIS
2. THREAT MODELING AND VULNERABILITY ANALYSIS
3. INDEPENDENT VERIFICATION OF ASSESSMENT PLANS AND EVIDENCE
4. MANUAL CODE REVIEWS
5. PENETRATION TESTING
6. ATTACK SURFACE REVIEWS
7. VERIFY SCOPE OF TESTING AND EVALUATION
8. DYNAMIC CODE ANALYSIS
9. INTERACTIVE CODE ANALYSIS

In light of Control SA-11, it appears that the 9 recommendations above do adhere to industry best practices. However, federal agencies and their software developers will likely be challenged when attempting to release software in today’s fast-paced, iterative world of software releases. The control methods listed above will likely add considerable delays to federal agencies wanting to release new or updated software that supports their mission objectives. Often, federal standards and guidelines driven by FISMA list many sound objectives, but they frequently fail to adequately describe how they can be achieved overall.

Today, many agencies are attempting to adopt DevOps fundamentals within their software development practices, while at the same time, desiring to move toward DevSecOps by adding security practices into the mix. Therefore, agencies are at a crossroads whereby they must (and should) adhere to the proposed NIST requirements, while at the same time trying to pivot quickly like their commercial counterparts who deploy multiple software releases per day. This represents quite the quandary, but it’s not insurmountable. The key is making use of security automation within their software development efforts.
When looking closer at the list above, notice that items 2, 3, 4, 6, and 7 can, in many cases, be performed before the application is developed. These items are often performed no more than once per application overall. On the other hand, Static Code Analysis (1.), Dynamic Code Analysis (8.), and Interactive Code Analysis (9.) should be performed during the software development process itself for every software version and updated sub-version. And finally, Penetration Testing (5.) is normally performed post-delivery and/or deployment. That being said, the real challenge agencies face is how to automate and accelerate the code analysis process during software development, and not allow security to become a roadblock to release.

Recently, and to help agencies chart this complex landscape, DLT partnered with the Institute for Critical Infrastructure Technology (ICIT) aka “The Cybersecurity Think Tank” and top government and industry leaders for an online discussion: Interactive Security Testing, DevSecOps, and NIST SP 800-53 Rev. 5., which was well attended. Jeff Hsiao, ICIT Contributor & Security Solutions Engineer, Checkmarx, AWS, and Dr. Ron Ross participated in the discussion and demonstrated their highly valuable technical insight pertaining to the topic. All agreed that Interactive Security Testing plays an important role in the code analysis process, however, agencies must also consider static analysis, open source analysis, and developer AppSec awareness and training. At the end of the day, vulnerability detection, remediation, and secure coding practices are the goals for all federal agencies.

Here at Checkmarx, we are experts at DevSecOps and fully deliver on automating code analysis and vulnerability remediation during the software development process. In fact, we scored highest for the DevOps/DevSecOps use case in the 2020 Gartner Critical Capabilities for Application Security Testing Report.  If you would like to learn more about how we can help your agency comply with the pending standards and guidelines from NIST, don’t hesitate to contact us here. Not only will our approach streamline all of your code analysis and vulnerability remediation efforts, we’ll measurably reduce your time to software release.

Stayin’ Put

GitLab’s users, whether they are Software Developers, DevOps, or AppSec engineers, want to consume as much of the application security scanner’s results as possible within GitLab. GitLab is already a complete DevOps platform from managing -> to planning -> to creating -> to releasing, so it is just common sense GitLab users would want to have security directly within GitLab. GitLab users can consume Checkmarx security-related vulnerability results at three different integration points:

• Merge Request Overviews
• GitLab Issues
• Security Dashboard (for GitLab Gold/Ultimate tier or public projects)

Every organization, even teams within the organization, will want to run security scanners at different points of the SDLC, but by best practice from Checkmarx, it is suggested to scan at the Merge Request stage. With security scanning completed at the Merge Request stage, an assessment can be performed with the scan results and the merge can be blocked, or GitLab Issues can be created. But, what kind of result data should be consumed?
Checkmarx provides:

• High level summary of CxSAST & CxSCA findings
• Data flow from source to sink within the source code
• Short summary of the specific vulnerability that was identified
• Links to just-in-time training (CxCodebashing) and online resources for remediation
• Links into Checkmarx platform for even more comprehensive results

CxFlow – Under the Hood

Checkmarx maintains a spring boot application called CxFlow, which acts as a scan and results orchestration tool to automate security scans and integrate the results into CI/CD tools such as GitLab. Some key features and capabilities include:

• Scan Initiation – CLI or Webhook Events
  • CxFlow can be configured in two different ways: using CxFlow from a command line interface or have CxFlow work as a server and listen for Webhook events. Once an event is triggered or received, the initiation of a Checkmarx scan will occur automatically.
  • Merge requests, or even commits of the source, will trigger an existing pipeline within GitLab’s CI/CD and initiate a scan via CxFlow; the existing pipeline just needs an edit to include a stage that will invoke CxFlow.
  • The scan initiation will either create a new project if it does not exist or update a current one.
• Results Management
  • As far as consuming results, the scan results are file based (csv, json, or xml) making it easy to import into defect tracking systems or dashboards.
  • CxFlow also drives a result feedback loop eliminating having to do manual intervention (opening and even closing defects).
  • You can always filter the results created based on any filtering criteria.
  • The results are easy to consume, in a way developers want to consume and most importantly, actionable.
• Defect Tracking
  • Consolidates issues of the same vulnerability type in the same file – instead of multiple issues, it is just one.
  • Once all references to the vulnerability type of that issue are fixed, the ticket will automatically close.
  • You can base it on policy – severity / CWE / vulnerability type or state (urgent / confirmed).
  • Defect tracking is also supported for both CxSAST and CxSCA results.
• Feedback Channels
  • Not only does it support GitLab Security Dashboard and GitLab Issues, but also Jira, Email, Service Now and Rally.
• Ease of Consuming the AST Service
  • Effortless option for the development teams to quickly scan projects.
  • There is no overhead when configuring and managing builds.
• Mass Effortless Scan Configuration
  • You can quickly automate the scan of multiple repositories.
  • Again, there is no overhead when configuring and managing builds of many repos.
• Automation with Developers’ Common Toolsets
  • In this case, GitLab.
  • You want to get the details of issues to those who must address them – the developers.
  • Drive security testing based on GitLab activity.
  • Publish issues to existing backlogs.
  • Keep developers within GitLab.
• Eliminate Unnecessary Manual Tasks with Checkmarx Automation Capabilities
  • Free up time to focus on things that matter.
  • Shift as far left as possible.
  • Constantly scanning the latest code.
  • Replaces need to scan in the IDE.

GitLab / Checkmarx Workflow

Below is a visual picture of the Checkmarx workflow with GitLab’s CI/CD.

Now let’s describe this flow in more detail: 

1. Setting Variables

Variables are needed to perform Checkmarx authentication and to define Checkmarx scan settings read by CxFlow. This can be set up per project or by “groups”. GitLab has an awesome feature where you can have a file as a Variable. We leverage this feature and have CxFlow’s yaml configuration file as a Variable.

2. Defining a Stage

Per GitLab best practice, application security testing should be done during the “test” stage of the pipeline. During the test stage of the pipeline, GitLab will pull the Checkmarx docker container where CxFlow CLI is stored. CxFlow CLI should then be invoked to initiate the scan based on the settings defined in the config file Variable.

3. CxFlow CLI Initiates the Scan

CxFlow receives the request with the Checkmarx project settings and the GitLab repository details. CxFlow performs the authentication into the Checkmarx server and then initiates a scan. It will wait for the scan to finish. 

4. Checkmarx Performs SAST & SCA Scans
   
5. CxFlow Parses Results and Updates GitLab

CxFlow waits until the scan is done, parses the results and will update the Security Dashboard, GitLab Issues, the Merge Request Discussion, or all three. If the issue has been fixed, it will automatically close it.

Go is Perfect

The motivation behind the creation of Go was that currently, there are many programming languages available. Each has its own pros and cons. There are some languages that are efficient, but not simple, like C and C++. And, on the other hand, there are simpler languages that are less efficient, like JS and Python.
But, a programming language should be perfect—both efficient and simple, right? Go is both, and a lot more. Let me elaborate a little further on why that is.

Go Syntax is Simple and Clean

Go syntax is something between C and Python with advantages from both languages. It has a garbage collector that is very useful.

• It does not have objects, but it supports structures (structs) and any type can have a method.
• It does not support inheritance, but does support compositions and interfaces.
• You can have a pointer to a variable, but at same time, you don’t have to worry about referring to its methods.
• It’s statically typed, but it’s non-strict because of the type inference.
• Its package-based code management reduces the number of code lines.
• And last but not least, Go has a simple concurrent model.

Let’s dig into some examples of the simplicity, but awesomeness of Go.

• Swapping between variables is simple:
  • b, a = a, b
• It allows you to import a package directly from GitHub or any other source manager:

o    import “github.com/pkg/errors”

• By starting a Goroutine, it supports concurrent routing:

o    go runConcurrently()

• Allows you to refer to a method of instance of some type, no matter if it’s a pointer or the actual instance:
  • instance.method()

Go is Efficient and Scalable

Thanks to the Go dependency model and its memory management, the compilation is very fast when compared to low-level languages, and even more so with high-level languages.
Go’s runtime performance is similar to C++ and C, making its performance quite notable.
In the context of scaling, Go is much faster than popular competitors thanks to the Goroutines model as you can see in the figure below.

When comparing Goroutines to Java threads, Goroutine threads consume ~2KB, while Java threads consume ~1MB.

Go is Widely Used and Super Easy to Learn

Go is an open source language with wide adoption and a fast-growing community. On the web, you can find lots of free and useful packages and many Q&As, FAQs, Tutorials, etc.
According to 2019 stack-overflow survey among developers, Go is one of the most popular languages. 8.2% of the survey respondents are programming in it, and 67.9% of the respondents mentioned Go as their most loved, dreaded, and wanted language. Go scored the highest rank (93% of the respondents) as a preferred language in a 2019 survey by Golang within Go developers, and as you can see in the Figure below, Go is growing in popularity.

In addition to that, Go is super easy to learn. Because of its friendly syntax and the great “Tour of Go” (that takes about two days to complete and covers all the basics you’ll need to get started programming in Go), after completing the tour, you will feel very confident with the language. When you start using the language, coding with it will become pretty easy overall. And after about two weeks of using it, it will likely become your preferred/native language.
Looking to quickly increase your knowledge of Golang security? Check out our Intro to Go Language guide!

So, hear this Gopher out!

You Better Get Going with Go.
Reference
HS, P. (2017, October 03). Episode 8: Interview with Ryan Dahl, Creator of Node.js. Retrieved July 07, 2020, from https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/

Pertaining to development tools, DevOps is also about automation of the different tooling in use that improves the speed of software delivery. Designed primarily for those embarking on DevSecOps initiatives, Checkmarx CxFlow integrates security into the existing tools so that secure software development can be achieved without requiring any extra tools. Using the existing tools already in place, CxFlow seamlessly operates in the background.

Checkmarx CxFlow is all about the automation of AST solutions into the tooling within today’s organizations. It was developed to address AST automation head-on, but there is more to CxFlow than meets the eye. Below is a list of the top three benefits organizations will experience when using CxFlow with their CxSAST and CxSCA deployments. Let’s delve a little deeper into what CxFlow is all about.

#1 The Most Shift-left Where Automation Can Occur

Traditionally, application security testing (AST) solutions on the market operate within the CI tooling in use and scans are normally performed after a merge/build has taken place – further to the right of the SDLC, so to speak. CxFlow on the other hand, allows organizations to shift that functionality to the left since CxFlow is an orchestration layer that simplifies the implementation and automation of AST in today’s modern development environments.
Using CI plugins to launch AST scans are still supported and even recommended, for example, launching scans from Jenkins, CircleCI, Travis CI, Bamboo, TeamCity, etc.

However, AST scans can now be integrated and launched directly from code management tools as well. CxFlow effortlessly integrates with application release orchestration and agile planning tools such as GitHub, GitLab, BitBucket, Azure DevOps, etc., enabling fully automated scanning of applications and the delivery of consumable results to the developers themselves.

Plus, CxFlow integrates directly with bug/defect tracking tools like Jira, Rally Software, ServiceNow, SonarQube, etc. This eliminates the need for time-consuming manual scan configurations and allows developers to publish and update findings based on policy to a defect/backlog management system for application teams to track.

#2 End-to-End Automation, from Scanning to Ticketing

Leveraging Checkmarx’s unique ability to scan uncompiled code, CxFlow automates the steps required to scan code earlier in the SDLC. This eliminates the need for time-consuming manual configuration of scans and allows developers to publish and update scan findings based on a pre-configured policy within the code management tools themselves. After the initial configuration, AST scan activity is performed hands-off with no human intervention required whatsoever beyond a pull request initiated by a developer.
With CxFlow, upon a pull request in the code management tools in use, the developer not only receives notifications from scans as comments that are related to functionality, but also as comments that are related to security, since CxFlow easily integrates with IDEs and code management tools in use. Just like that, the developer is able to have their code reviewed once for all bugs and would be able to close the full feedback loop with ticketing systems, all while the code is still fresh in their mind.  This allows developers to:

• Catch and fix vulnerabilities during the coding phase (earliest stage of development).
• Work as usual with no disruptions, no new tools, no additional security reviews needed, etc.
• Treat security bugs and functional bugs alike and allows them to immediately address those bugs within the code branch(es) they’re currently working on.
• Reduce the overhead of manually opening, validating, and closing security tickets without spending countless hours in bug tracking/ticketing management systems.

#3 Removes Friction Between Developers and DevOps/AppSec Teams

CxFlow eliminates the manual and time-consuming configuration per project within DevOps, thereby removing the friction between developers and DevOps teams when needing to add scanning steps into the jobs of all CI pipelines, since adding jobs/steps to scan code is challenging using the older CI-scan model. Today, CxFlow:

• Simplifies the AST lifecycle through automation into the tools already in use by taking a web listener approach, listening for events from the source code repositories and triggering AST scan actions upon such an event.
• Enables developers to have little if any intimate knowledge of CxSAST or CxSCA solutions since developers receive their automated scan reviews as comments/reports right from the repositories, not the AST solutions deployed.
• Works off the concept of a protected-branching strategy whereby you can configure master, develop, and security branches, for example, that are all deemed protected. This means that pull requests, push events, etc. will trigger scans and produce results when any code changes are made that are associated with those protected branches.
• Reduces TCO and improves ROI for scanning tools by reducing the need to manage and maintain multiple CI plugins concerning installation, updates, etc., when multiple CI solutions are in use.

Conclusion

CxFlow streamlines the configuration and orchestration between the development tool set and the Checkmarx Software Security Platform to drive AST automation. With this, organizations can instantly onboard their development, security, and operations teams and simplify the governance of their security policies and DevSecOps processes.

The traditional AST solution providers are leaving developers behind, because without the ability to scan source code directly, the traditional players can’t efficiently work within code management tools similar to Checkmarx.

Clearly, integration is key to automation and CxFlow enables the most shift left approach where automation can actually occur within the SDLC—changing the way AST solutions are integrated with in all DevOps environments.

• In 2018, Denial-of-Service by External Contract, and Reentrancy, were the top 2 issues. However, the issues were are now remedied. You can learn more about Reentrancy in our recent research blog: Checkmarx Research: Solidity and Smart Contracts from a Security Standpoint. When Solidity v0.6.x was released that introduced a lot of breaking changes, 50% of scanned Smart Contracts were not even ready for Solidity compiler v0.5.0. This becomes even more relevant since 30% of the Smart Contracts use deprecated constructions (e.g., sha3, throw constant, etc.), and 83% had issues with the compiler version specification (pragma).
• Although visibility issues didn’t make it in the 2018 Top 10 list, nor in this updated version, they have increased by 48%. You can read more about this issue in our previous blog and the official documentation.

The table below compares the changes between the 2018 and 2020 Top 10 Common Issues lists. The issues were sorted by severity and prevalence.

Solidity Top 10 Common Issues

S1 – Unchecked External Call

This was the third most-common issue on our previous Top 10 list. Since the top 2 issues are now resolved, Unchecked External Call has moved up to the most common issue in the 2020 updated list.
Solidity low-level call methods (e.g., address.call()) do not throw an exception. Instead, they return false if the call encounters an exception. On the other hand, contract calls (e.g., ExternalContract.doSomething()) automatically propagate a throw if doSomething() throws.
Transferring Ether using addr.send()is a good example where unsuccessful transfers should be handled explicitly by checking the return value, but this is also valid for other external calls.

S2 – Costly Loops

Costly loops moved from forth on the Top 10 list to second. Despite the fact that the top 2 issues from our previous list are resolved, the number of affected Smart Contracts increased by almost 30%.
Computational power on Ethereum environments is paid (using Ether). Thus, reducing the computational steps required to complete an operation is not only a matter of optimization, but also cost efficiency.
Loops are a great example of costly operations: as many elements an array has, more iterations will be required to complete the loop. As you may expect, infinite loops exhaust all available gas.

If an attacker is able to influence the elements array length, then they will be able to cause a denial of service, preventing the execution to jump out of the loop. Although it was far from the Top 10 common issues, array length manipulation was found in 8% of the scanned Smart Contracts.

S3 – Overpowered Owner

This is a new entry in the Top 10 list, affecting approximately 16% of the scanned Smart Contracts.
Some contracts are tightly coupled to their owner, making some functions callable only by the owners address, as in the example below.

Both doSomething() and doSomethingElse() functions can only be called by the contract owner: the former uses the onlyOwner modifier, while the later enforces it explicitly. This poses a serious risk: if the private key of the owner gets compromised, then an attacker can gain control over the contract.

S4 – Arithmetic Precision

Solidity data types are cumbersome due to the 256 bits Virtual Machine (EVM). The language does not offer a floating point representation, and data types shorter than 32 bytes are packed together into the same 32 bytes slot. With this in mind, you should expect precision issues.

When division is performed before the multiplication, as in the example above, you should expect huge rounding errors.

S5 – Relying on tx.origin

Contracts should not rely on tx.origin for authentication, since a malicious contract may play in the middle, draining all the funds: msg.sender should be used instead.

You’ll find a detailed explanation of Tx Origin Attacks on Solidity’s documentation. Long story short, tx.origin is always the first account in the call chain, while msg.sender is the immediate caller. If the last contract in the chain relies on tx.origin for authentication, then the contract in the middle will be able to drain the funds, since no validation is performed on who’s calling (msg.sender).

S6 – Overflow / Underflow

Solidity’s 256 bits Virtual Machine (EVM) brought back overflow and underflow issues as demonstrated here. Developers should be extra careful when using uint data types in for-loop condition, since it may result in infinite loops.

In the example above, the next value for i when its value is 0 will be 2²⁵⁶-1, that makes the condition always true. Developers should prefer <, >, != and == for comparison.

S7 – Unsafe Type Inference

This issue moved up two positions, now affecting more than 17% of Smart Contracts then before.
Solidity supports Type Inference, but there are some quirks with it. For example, the literal 0 type-infers to byte, not int as we might expect.
In the example below, the type of i is inferred to uint8: the smallest integer type sufficient to store the right-hand side value. If elements has more than 256 elements, we should expect an overflow.

Explicitly declaring data types is recommended to avoid unexpected behaviors and/or errors.

S8 – Improper Transfer

This issue dropped from sixth to eighth in the Top 10 list, affecting now less than 1% of the scanned Smart Contracts.
There is more than one way to transfer Ether between contracts. Although calling the addr.transfer(x) function is the recommended way, we still found contracts using send() function instead.

Note that addr.transfer(x) automatically throws an exception if the transfer is unsuccessful, mitigating the Unchecked External Call issues previously discussed: S1.

S9 – In-Loop Transfers

When Ether is transferred in a loop, if one of the contracts cannot receive it, then the whole transaction will be reverted.

An attacker may take advantage of this behavior to cause a denial-of-service, preventing other contracts to receive Ether.

S10 – Timestamp dependence

This was fifth in the previous version of the Top 10 list.
It’s important to remember that Smart Contracts run on multiple nodes on a different time. The Ethereum Virtual Machine (EVM) does not provide clock time and the now variable, commonly used to obtain a timestamp, is in fact an environment variable (an alias of block.timestamp) which miners can manipulate.

Since miners can manipulate environment variables currently, its value should only be used in inequalities >, <, >=, and <=.
When looking for randomness, consider the RANDAO contract, which is based on a Decentralized Autonomous Organization (DAO) that anyone can participate in, being the random number generated by all participants together.

Conclusion

When comparing the 2018 and 2020 Top 10 Common Issues lists, we can observe some progress concerning development best practices, especially those impacting security. Seeing the 2018 top 2 issues, Denial-of-Service by External Contract, and Reentrancy, moving away from the top 10 is a positive sign, but there’s still important steps to take to avoid common mistakes.
Remember that Smart Contracts are immutable by design, meaning that once created, there’s no way to patch the source code. This poses a great challenge concerning security and developers should take advantage of the available application security testing tools to ensure source code is well-tested and audited before deployment.
Solidity is a very recent programming language that is still maturing. Solidity v0.6.0 introduced a few breaking changes and more are expected in the upcoming versions.
Discovering issues and risks like the ones mentioned herein is why the Checkmarx Security Research team performs investigations. This type of research activity is part of their ongoing efforts to drive the necessary changes in software security practices among organizations worldwide.

References

• Checkmarx Research: Solidity and Smart Contracts from a Security Standpoint
• Solidity official documentation
• Solidity Security Considerations: tx.origin
• Type Inference – Wikipedia
• RANDAO: A DAO working as RNG of Ethereum
• SmartCheck: Static Analysis of Ethereum Smart Contracts
• Recommendations for Smart Contract Security in Solidity